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

Status: RESOLVED WORKSFORME

(Tech Evangelism Graveyard :: English US, defect)

Description

[Simon Willison]

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.

Comment 1

[Simon Willison]

Attachment: Test case demonstrating the problem

Comment 2

[Jesse Ruderman]

See also bug 139040, "JavaScript interpreter tries to parse 404 messages".

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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

[Bob Clary [:bc] (inactive)]

Nate, can you help us out here?

Comment 6

[Edward Ho]

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?

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

That sounds like the right thing to do.

Comment 8

[Toby Elliott]

(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.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(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

[Toby Elliott]

(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

Comment 11

[Hallvord R. M. Steen [:hallvors]]

404
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:22.0) Gecko/20100101 Firefox/22.0

Comment 12

[Hallvord R. M. Steen [:hallvors]]

(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? ;-))