All users were logged out of Bugzilla on October 13th, 2018

yahoo.com - External scripts with 400 status code fail to execute

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
13 years ago
4 years ago

People

(Reporter: swillison, Unassigned)

Tracking

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

A <script src=""></script> tag that points at a script that returns a 400 Bad Request error (indicating the client made a mistake in its request) is not executed, even if the content-type is set to text/javascript.

This breaks interoperability with Yahoo!'s new JSON web service APIs, which serve up JavaScript for use with external script tags but returns a 400 status code (and executable JavaScript) in the case of a bad request.

Reproducible: Always

Steps to Reproduce:
1. See attached demonstration page.
Actual Results:  
No alert box appears.

Expected Results:  
An alert box should appear with an error message in it.
(Reporter)

Comment 1

13 years ago
Created attachment 206341 [details]
Test case demonstrating the problem
(Reporter)

Updated

13 years ago

Comment 2

13 years ago
See also bug 139040, "JavaScript interpreter tries to parse 404 messages".
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?

Comment 5

13 years ago
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

Comment 6

13 years ago
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.

Comment 8

13 years ago
(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.

Comment 10

13 years ago
(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.