1437206 - Intermittent "Invalid Header" When Logging in to Allrecipes.com (HTTPS Specific)

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Kevin]

Attachment: 400 error.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180206200532

Steps to reproduce:

1) Go to Allrecipes.com
2) Create an account if need be (this might trigger the bug)
3) Log in to new account
you may have to repeat this a couple of time


Actual results:

See screenshot.

Error is produced: Bad Request - Invalid Header

if you go into the developer console, and right click on the request, choose copy -> copy cURL, the resulting curl command works every time.  this does not reproduce in any other browser either.  Also unable to reproduce in OSX, and Mobile Firefox.  Appears to be Windows specific.

Also appears to be related to how SSL certificates are handled.  If you put Firefox under fiddler, with it's HTTPS decoding (essentially a MiTM attack) it does not appear to reproduce anymore either.


Expected results:

behavior should match Firefox on other systems

Comment 1

[Michal Novotny [:michal]]

Attachment: log.txt-main.10298

At the first look I don't see anything wrong in the headers. Nick, could this be h2 related? See transaction 0x7f11a8d1ac00.

Comment 2

[u408661]

So from our side, nothing looks wrong with the headers. But, as the reporter, I've been unable to reproduce this with curl, while I've been able to reproduce relatively easily on Firefox (this is on OS X, so it's not platform-specific as the reporter indicated).

Without knowing what went wrong from the server's perspective (more specific than "invalid header name" that appears in the 400 response body), this will be a tricky one to track down. I can spend some time with wireshark, curl, and firefox, and compare the frames that are sent, but even that might not be helpful, as different implementations may make different (valid) decisions about how to compress headers.

Comment 3

[Kevin]

I did some further investigation on our end.  the error is caused by a feature in a load balance called f5.  when the feature, http/2 profile, is enabled Firefox produces this error.

further information, f5 version 13.0.0 does not trigger this.  only 13.1.0 does.

in fact, it appears it be a known issue with f5: https://devcentral.f5.com/questions/problem-with-http2-profiles-on-13101-57275

Comment 4

[u408661]

Thanks, sounds like this is a server-side issue then, that can either be worked around or upgraded to fix.