1428252 - Scripts don't load

Status: RESOLVED WORKSFORME

(Core :: Networking, enhancement, P3)

Description

[Eric Tsai (no more review request accepted)]

Original reported by user thony8@github in https://webcompat.com/issues/14666

Go to the website directly. scripts are not loaded.
In dev tool network panel, we can see the script is transferred, but nothing in response payload, I guess there is something wrong in server side so Firefox get something wrong, so script is not parsed.

layout.css.servo.enabled: true
https://webcompat.com/uploads/2018/1/622550cb-f156-4e28-a2f5-ed6172008b90.jpg

Comment 1

[Kershaw Chang [:kershaw]]

Attachment: screenshot of script response

This screenshot shows that the status of bootstrap.min.js is 302, but there is no Location header in response header. Even so, we still treat this as a normal response [1] and continue to receive the data.
However, ScriptLoader calls HttpBaseChannel::GetRequestSucceeded at [2] to check if the status code is 2xx, and the result is false. so, ScriptLoader thinks this is an invalid request and discards the script.



[1] https://searchfox.org/mozilla-central/rev/652fbd6270de0d3ec424d2b88f8375ff546f949f/netwerk/protocol/http/nsHttpChannel.cpp#5561-5564
[2] https://searchfox.org/mozilla-central/rev/652fbd6270de0d3ec424d2b88f8375ff546f949f/dom/script/ScriptLoader.cpp#3076

Comment 2

[Kershaw Chang [:kershaw]]

(In reply to Kershaw Chang [:kershaw] from comment #1)
> Created attachment 8940096 [details]
> screenshot of script response
> 
> This screenshot shows that the status of bootstrap.min.js is 302, but there
> is no Location header in response header. Even so, we still treat this as a
> normal response [1] and continue to receive the data.
> However, ScriptLoader calls HttpBaseChannel::GetRequestSucceeded at [2] to
> check if the status code is 2xx, and the result is false. so, ScriptLoader
> thinks this is an invalid request and discards the script.
> 
> 
> 
> [1]
> https://searchfox.org/mozilla-central/rev/
> 652fbd6270de0d3ec424d2b88f8375ff546f949f/netwerk/protocol/http/nsHttpChannel.
> cpp#5561-5564
> [2]
> https://searchfox.org/mozilla-central/rev/
> 652fbd6270de0d3ec424d2b88f8375ff546f949f/dom/script/ScriptLoader.cpp#3076

I think we can do either:
1. Ask the server side to fix their response header.
2. Modify the behavior of ScriptLoader to allow this special case, since chrome can load this page without problem.

Patrick, what do you think?
Thanks.

Comment 3

[Honza Bambas (:mayhemer)]

All of the responses, including the top level page are 302 w/o any Location header.  There is no UA sniffing, so the same broken response is obtained in Edge/Chrome as well.

It seems to me that they are just trying to redirect to https version of the page in all cases (like forced https everywhere by the server.)

We purposely show the content of a 30X pages since those could show (have useful links) where the content is actually located.

Edge is not even willing to show the top level page saying "Hmmm...can’t reach this page".

Chrome ignores missing Location response header and shows the top level content, as we do, and also allows scripts to parse.  It seems to me they are just trying to make things work as much as possible.

IMO, we behave the best way.  I believe letting scripts with 30X broken responses to parse/run is a bad thing from the security point of view (no attack by hand, tho, to demo on).

Since the https version of the page loads well, I don't think there is anything to fix on our side.

Giving Patrick the final word, but for me a WONTFIX.

Comment 4

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 5

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 6

[Mike Taylor [:miketaylr]]

This seems to be working now.