All users were logged out of Bugzilla on October 13th, 2018
I believe this is invalid. An error response indicates that the resource is not available. Period. If there is a response body it may be shown to the user to indicate what went wrong (SHOULD in RFC 2616 section 10.4), but simply substituting the error response body for the expected response (eg executing it as JS in this case) is very much a violation of the HTTP spec as I see it. The only reason I'm leaving this open is because we may want to evangelize Yahoo here.
Agreed, INVALID for this component, and we should evang this hard. Who do we know at Yahoo that's close to this (otherwise righteous) JSON stuff?
Nate, can you help us out here?
Assignee: general → english-us
Status: UNCONFIRMED → NEW
Component: DOM → English US
Ever confirmed: true
OS: MacOS X → All
Product: Core → Tech Evangelism
QA Contact: ian → english-us
Hardware: Macintosh → All
Summary: External scripts with 400 status code fail to execute → yahoo.com - External scripts with 400 status code fail to execute
Version: Trunk → unspecified
My current plan is to return a 200 with these JSON errors when the callback parameter is specified (client is definitely using script tag) Thoughts?
That sounds like the right thing to do.
(In reply to comment #7) > That sounds like the right thing to do. > Return a 200 even though there's a problem with the request? That seems very hacky from both a client (successful request) and server (successful request logged) perspective. >If there is a response body it may be shown to the >user to indicate what went wrong (SHOULD in RFC 2616 section 10.4), This is the issue. There is no way to access the response do this at this time. Without a 200 error code (which we are now issuing with the callback request no matter what), the data just vanishes.
(In reply to comment #8) > (In reply to comment #7) > > That sounds like the right thing to do. > > > > Return a 200 even though there's a problem with the request? That seems very > hacky from both a client (successful request) and server (successful request > logged) perspective. I'm not familiar with the Yahoo JSON api, but i'm wondering what you mean by "problem with the request". The 200 vs 400 codes are http level error codes, are the bad requests really bad at a http level? Or are they bad at an application (that happens to run over http) level? If the error is on an application level then returning a 200 response feels ok to me, all other lower levels of the OSI model (physical layer, TCP/IP layers) has returned valid responses. From a client point of view it feels very wrong to execute the contents of a 400 error. That would cause us to efficently ignore the return code. Maybe the right solution here is to add an onerror attribute to the <script> element. That should be fired once the 400 response is recieved. Please file a bug otherwise. I could even possibly see an argument for providing access to the response body in the event given to the onerror handler. Though other people more familiar with http networking would need to ok that, and there are security related issues with doing it.
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > I'm not familiar with the Yahoo JSON api, but i'm wondering what you mean by > "problem with the request". The 200 vs 400 codes are http level error codes, > are the bad requests really bad at a http level? Or are they bad at an > application (that happens to run over http) level? You are correct, the problem is at an application level. From that perspective, the 200 is correct. As we move into a more webservice-oriented world, we may need ways to indicate transport-ok-request-not. Your suggestion of an onerror attribute is definitely one workable approach. For now, I'm happy to leave it as a 200 on our end, but it's something to think about moving forwards. Thanks, Toby
404 Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:22.0) Gecko/20100101 Firefox/22.0
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
(Closed as 404 with tongue in cheek :-p - site says service no longer exists, so it's sort of application-level 404 while network-level 200 - exactly what the bug itself is about, no? ;-))
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.