385737 - HTTP Headers longer than 10kb are dropped

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, defect)

Description

[Marc]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

I'm using the prototype AJAX-framework to do some AJAX requests. Prototype offers a way to pass the data as JSON and have it ready as an object in the javascript function that is called when the request succeeds. Therefor you need to send the JSON data as an X-JSON header in your response (see: http://franktank.com/blog/scripts/return-json-array-using-ajax-and-prototype/ for example). 
Whenever the header value exeeds 10kb firefox is not responding to the server response. You send you AJAX request, the server sends the answer but firefox does nothing.
This happens with Firefox for Windows and Linux also with Gran Paradiso (tested on Windows only). IE, Opera and Safari (Win) are processing the response even if it is longer than 10kb.
I also could not find any restriction to a header-field-body-length in the specification.

Reproducible: Always

Steps to Reproduce:
Do a (ajax)request where the answer has a header field body that contains data >= 10kb.
Actual Results:  
Firefox is not passing the response to the javascript engine, so no result is ever getting there (as if the server would have never answered).

Expected Results:  
The response should be processed as if the header field is shorter.

Comment 1

[Martijn Wargers (dead)]

Is there an example somewhere where the bug can be seen?

Comment 2

[Phil Ringnalda (:philor)]

See http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/protocol/http/src/nsHttpTransaction.cpp&rev=1.102&mark=685-689#668 as added by bug 152697

Comment 3

[Marc]

http://www.itec-services.de/ajaxTest/ajaxTest.php

Here you can see the test i made. 

I've seen that it was limited for security reasons. But i don't know how this limit of 10kb (or better more data in the header) could cause a Dos. As I see this, it doesn't make too much difference if i send it in the header or the body. But in the header i have a name-value-list, that's why i think prototype is using this way. Maybe there is a limit what Firefox (or any browser) can handle, but i don't know FF this good.

Comment 4

[u7736]

Why don't you use the body? Carrying data is what it's for.

Even if you can get every browser in the world to support such headers, it doesn't mean intermediaries will. Yes, the spec doesn't specifically limit the length of headers, but it doesn't preclude implementations from doing so -- and almost all do. 

Comment 5

[Marc]

Yes, the body is for carrying data. But i'm using it like this, because it is offered by prototype and it is a nice way for accessing the data you sent. Because it is transformed into a javascript object and passed over to your functions by the framework automatically when sent as a X-JSON header.

As I see this, there is practically not much difference between the header and the body when beeing send, only the header contains data that shall be transfered first, before the body.  From the HTTP point of view this might not be the same, but also there i don't see too much differences.

I don't know about the internas of how the received http data is handled by the browser, but from my point of view there should not be any big difference. If I send a very big inline body, the memory consumption is also growing and the browser might stop responding.

Comment 6

[Boris Zbarsky [:bzbarsky]]

One big difference is that the body can be handled in a streaming fashion without having to buffer it all up, in many cases.  Headers have to come as a single unit.

Comment 7

[Robert Sayre]

I think we should WONTFIX this unless someone can figure out the IE7 limit.

Comment 8

[u7736]

One point of data; Squid has a default 20K limit for *all* headers in a request;
  http://www.squid-cache.org/Versions/v2/2.6/cfgman/request_header_max_size.html

From a quick look at the code, that also includes the request-uri.