5 ms·

[flagged]

ghoshbishakh 3mo ago
100% - although it is stunning to see since most LLMs get CORS questions right (which is surprising since they trained on all sorts of incorrect data).
- Finbel 3mo ago
  Maybe it’s like that trick where if a thousand people guess the amount of beans in a jar almost all of them will be wrong but their average will be very close to, if not, correct.
  - TeMPOraL 3mo ago
    Possibly, but at a semantic level.
  - mattkenefick 3mo ago
    they probably weight documentation higher
    - xnx 3mo ago
      They're applying trust factors similar to PageRank.
- tgv 3mo ago
  I think many (most?) have preferred sources. I would weight Wikipedia and MDN higher than Snurk Grubble's blog in training, no matter what the topic.
  - marcosdumay 3mo ago
    Also, you can count on most developers to reach the documentation only as a last resort, and try every random blog first.
- PunchyHamster 3mo ago
  It's probably trained more on fixes on incorrect CORS than the problems
- mhh__ 3mo ago
  They look for latent structure in the data.
gib444 3mo ago
Guidelines say to edit out swipes, so your comment can be edited to just: ""
paulddraper 3mo ago
Depressing. While CORS is not intuitive, it is understandable by RTFM. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...
JimDabell 3mo ago
I think perhaps it’s generational. If you were a web developer before CORS existed, then you understand that cross-domain requests were forbidden all along and CORS was created to bypass this security. Therefore to do the thing you want to do, you need to enable CORS. No problem, that’s pretty easy. If you only picked up web development after CORS existed, then you try to make a cross-origin request; the browser understands that it isn’t allowed; the browser tries to do a CORS preflight request; the preflight request fails; and the browser reports a CORS error in the console. So if you don’t understand what’s going on, don’t RTFM, and just guess, you’re going to guess that CORS is the thing that is blocking the request and that you need to disable CORS. And that leads you directly into a confusing mess because you are trying to do the exact opposite of what you need to do. CORS is the solution to your problem, not the cause of it. It doesn’t help matters that a whole bunch of people with the same misunderstanding will confidently repeat that misunderstanding in tutorials and online discussions.
- brazukadev 3mo ago
  > So if you don’t understand what’s going on, don’t RTFM, and just guess, you’re going to guess that CORS is the thing that is blocking the request and that you need to disable CORS. And that leads you directly into a confusing mess because you are trying to do the exact opposite of what you need to do. CORS is the solution to your problem, not the cause of it. Great explanation. The name is quite obvious actually, Cross-Origin Resource Sharing. People should understand if they read it.
- jkrejcha 3mo ago
  Gonna play devil's advocate here I think to some extent CORS and SOP are a bit equivocated somewhat intentionally... i.e. CORS is a used as a shorthand for SOP because CORS is a more well known term, especially in its acronymized form. Consider for example the error I get when opening up the console on Google's homepage > Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://play.google.com/log?format=json&hasfast=true https://play.google.com/log?format=json&hasfast=true. (Reason: CORS request did not succeed). Status code: (null). There is a reference to the SOP in here but it starts off with "Cross-Origin Request" and also says "CORS request did not succeed". Which makes it sound like CORS is the problem or the thing doing the blocking or that "CORS" is enforcing the "Same Origin Policy". Chrome, I've heard, is even more cryptic Also, it feels like one of those things that are a little pedantic to mention in a discussion irl, so that's probably why the term CORS sticks and the term SOP doesn't

[flagged]

100% - although it is stunning to see since most LLMs get CORS questions right (which is surprising since they trained on all sorts of incorrect data).

Finbel 3mo ago
Maybe it’s like that trick where if a thousand people guess the amount of beans in a jar almost all of them will be wrong but their average will be very close to, if not, correct.
- TeMPOraL 3mo ago
  Possibly, but at a semantic level.
- mattkenefick 3mo ago
  they probably weight documentation higher
  - xnx 3mo ago
    They're applying trust factors similar to PageRank.
tgv 3mo ago
I think many (most?) have preferred sources. I would weight Wikipedia and MDN higher than Snurk Grubble's blog in training, no matter what the topic.
- marcosdumay 3mo ago
  Also, you can count on most developers to reach the documentation only as a last resort, and try every random blog first.
PunchyHamster 3mo ago
It's probably trained more on fixes on incorrect CORS than the problems
mhh__ 3mo ago
They look for latent structure in the data.

gib444 3mo ago

Guidelines say to edit out swipes, so your comment can be edited to just: ""

paulddraper 3mo ago

Depressing. While CORS is not intuitive, it is understandable by RTFM. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...

JimDabell 3mo ago

I think perhaps it’s generational. If you were a web developer before CORS existed, then you understand that cross-domain requests were forbidden all along and CORS was created to bypass this security. Therefore to do the thing you want to do, you need to enable CORS. No problem, that’s pretty easy. If you only picked up web development after CORS existed, then you try to make a cross-origin request; the browser understands that it isn’t allowed; the browser tries to do a CORS preflight request; the preflight request fails; and the browser reports a CORS error in the console. So if you don’t understand what’s going on, don’t RTFM, and just guess, you’re going to guess that CORS is the thing that is blocking the request and that you need to disable CORS. And that leads you directly into a confusing mess because you are trying to do the exact opposite of what you need to do. CORS is the solution to your problem, not the cause of it. It doesn’t help matters that a whole bunch of people with the same misunderstanding will confidently repeat that misunderstanding in tutorials and online discussions.

brazukadev 3mo ago
> So if you don’t understand what’s going on, don’t RTFM, and just guess, you’re going to guess that CORS is the thing that is blocking the request and that you need to disable CORS. And that leads you directly into a confusing mess because you are trying to do the exact opposite of what you need to do. CORS is the solution to your problem, not the cause of it. Great explanation. The name is quite obvious actually, Cross-Origin Resource Sharing. People should understand if they read it.
jkrejcha 3mo ago
Gonna play devil's advocate here I think to some extent CORS and SOP are a bit equivocated somewhat intentionally... i.e. CORS is a used as a shorthand for SOP because CORS is a more well known term, especially in its acronymized form. Consider for example the error I get when opening up the console on Google's homepage > Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://play.google.com/log?format=json&hasfast=true https://play.google.com/log?format=json&hasfast=true. (Reason: CORS request did not succeed). Status code: (null). There is a reference to the SOP in here but it starts off with "Cross-Origin Request" and also says "CORS request did not succeed". Which makes it sound like CORS is the problem or the thing doing the blocking or that "CORS" is enforcing the "Same Origin Policy". Chrome, I've heard, is even more cryptic Also, it feels like one of those things that are a little pedantic to mention in a discussion irl, so that's probably why the term CORS sticks and the term SOP doesn't