Summary: | Please allow request lines longer than 8k | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | Nirgal Vourgère <jmv_deb> |
Component: | Core | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | RESOLVED LATER | ||
Severity: | minor | Keywords: | MassUpdate |
Priority: | P2 | ||
Version: | 2.2.16 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
URL: | http://bugs.debian.org/638011 |
Description
Nirgal Vourgère
2012-02-05 17:27:48 UTC
The data being read isn't a request line or a request-anything, so why would that limit apply? Maybe I extracted the wrong bits of code, but in essence the problem is this: Apache truncates request lines passed to a CGI script to ~8kB, and there is apparently no way of changing that setting. On 2.2 I was able to send a request line >8k and see its value in the REQUEST_URI environment variable. Can you share the details of the test case? I'm not sure this is related, but since commit 1200947 [1], documentation [2] says: "Under normal conditions, the value should not be changed from the default. Also, you can't set this higher than 8190 without modifying the source and rebuilding." See also bug 51665 [3] [1] https://httpd.apache.org/docs/2.2/en/mod/core.html#limitrequestline [2] https://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/docs/manual/mod/core.xml?r1=1166612&r2=1200947&pathrev=1200947 [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=51665 I came across this issue when diagnosing a problem with the IkiWiki CGI. Details of the IkiWiki issue can be found here (with pointers to a similar bug in another software): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638009 In essence, the problem is that the IkiWiki CGI script generates an HTTP 302 response, with a very long `Location: ...` line (~16k; basically it embeds the text of the whole Wiki page in the http:// URL as a query parameter). Then Apache (I was using the Debian "squeeze" one) truncated the line, apparently at ~8k. The IkiWiki bug has been corrected since (it shouldn't have issued a redirect in the first place), so current version will not exhibit that behavior. Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated. |