User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155 Safari/537.36 Steps to reproduce: I'm a developer with spideroak.com. The OMVA we have built for our SMB and Enterprise customers has an option to `View User's Data` from a user's detail page. The process for linking to the user's data follows a 4 step process wherein the page is directed through a couple of channels, landing at the user's url: - Click the button. This kicks off the process of grabbing user's validation through an escrow process. - The process returns a 302 redirect with credentials to our internal processor. - The internal processor validates and returns a 303 with the supplied destination url. - Manager can then view user's data. Due to certain policies, I cannot provide a reduced test case. However, I can direct you to a secured a minimal as possible version of our product upon request for reproduction. Actual results: From the 303, the final supplied url should load. But Firefox spins for a while then just times out. Expected results: Firefox should follow 303 to the final destination. Note: This works in Firefox 38.0.5 but causes the above issue in 39.0.3 to Nightly 43.0a1

Maybe there is a regression in FF39. A dev will probably ask you an access to the testcase.

please supply an http log of the test case. When you upload the attachment you can mark it private. https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

(In reply to Patrick McManus [:mcmanus] from comment #2) > please supply an http log of the test case. When you upload the attachment > you can mark it private. > > https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging The log files generated from this exceed the upload limit. I can attach them offsite in a spideroak.com ShareRoom. Alternatively can I trim the logs at a certain point? Currently the log generated from the 38.0.5 test case is 37.2MB and the one from 40.0.2 is 51.1MB Also - I didn't see an option in the Create New Attachment view for marking the files as private.

You can upload the log file to a third-party cloud service like Dropbox, Mediafire etc. and post the download link here.

on the upload screen there is a checkbox under privacy.. but if you're just going to include a link in a comment (which is fine) then you want the "make comment private" checkbox next to "additional comments"

oh - and those logs are text and compress very well..

(In reply to Patrick McManus [:mcmanus] from comment #6) > oh - and those logs are text and compress very well.. Here you go. This ShareRoom will be available till the conclusion of this ticket. https://spideroak.com/browse/share/Rustic/firefox-logs

if you find the 303 response in the log (see other is a good string to search for) it has a content-length of 246 but there are no body bytes sent after the headers and the server closes the connection. We detect that, correctly, as a malformed response. (and this is a new behavior) The fastest fix for you would be to make it well formed.. (c-l 0, or send a body, or just omit c-l as long as you close the connection) Given that this is a redirect and the response body is not all that important, I think we should also consider the firefox behavior an overreaction and let this slide on non 2xx cases for webcompat reasons. I'll attach a patch soon bagder ni just fyi

Yeah, seeing that there are now more than one case of this and they're rather obscure to the users I can see how we might need to backpedal once again. Do you plan on loosening the check for redirects in particular or do it for all non-2xx status responses?

(In reply to Daniel Stenberg [:bagder] from comment #9) > Yeah, seeing that there are now more than one case of this and they're > rather obscure to the users I can see how we might need to backpedal once > again. Do you plan on loosening the check for redirects in particular or do > it for all non-2xx status responses? can you include other bug numbers here?

I was thinking about bug 1186830 in addition to this.

Comment on attachment 8655007 [details] [diff] [review] dont enforce h1 framing on non 2xx Looking good!

Comment on attachment 8655007 [details] [diff] [review] dont enforce h1 framing on non 2xx Approval Request Comment [Feature/regressing bug #]:237623 - gecko 39 [User impact if declined]: minor webcompat issue with non compliant http responses can lead to failed navigations. We can loosen the rules a little bit with this patch and still obtain the goal of 237623. [Describe test coverage new/current, TreeHerder]: new xpcshell test [Risks and why]: extremely low risk - 237623 tightened handling of non-compliant responses, and this change brings us back to where we were for a small subset of them for reasons of web compat. [String/UUID change made/needed]: none

Benny, would you be able to verify the fix on Nightly build from 09-02 or later? I am hoping the fix will be in the next Nightly build. Thanks!

Adding the keyword regression and setting status affected for 41+

(In reply to Ritu Kothari (:ritu) from comment #20) > Benny, would you be able to verify the fix on Nightly build from 09-02 or > later? I am hoping the fix will be in the next Nightly build. Thanks! Absolutely. I'll test as soon as the build comes out.

FF Nightly 43.0a1 (2015-09-02) fails. Will try again tomorrow. Let me know if you need anything.

Fix works as of Nightly 43.0a1 (2015-09-03) Do you know when this will go to production? Thanks!

(In reply to Benny M from comment #25) > Fix works as of Nightly 43.0a1 (2015-09-03) > > Do you know when this will go to production? > > Thanks! Many Thanks Benny! This should in 41.0b8 and 41 when it goes live.

Comment on attachment 8655007 [details] [diff] [review] dont enforce h1 framing on non 2xx Given that the patch was verified, I feel much more confident uplifting to Aurora42 and Beta41.

Can confirm that this issue is resolved in 41.0! Thanks a ton for all your work and your attention to this issue!

Usually we don't document bug fixes (unless very old). In this case, I think the site-compat info will be enough.

Added the site compatibility doc: https://www.fxsitecompat.com/en-US/docs/2015/303-and-307-redirects-after-302-are-not-followed/