Typing long comment then attaching patch fails with "Request-URI Too Large" or HTTP 400.

[Stéphane Gourichon]

Summary :

* Typing a long comment in a bug report comment box then following "Add attachment or patch" link below box fails with
 "400 Bad request - Your browser sent an invalid request. " or even "Request-URI Too Large".
* The comment is not submitted and is generally lost for the reporter in most case (although Firefox extension "Form History Control" may help the user to recover his contribution and resubmit it, some other browsers may provide similar tools).
* As a consequence, time invested in contributing to launchpad base communities is in some cases lost for everyone.

How to reproduce:

* open any existing bug page, this very bug for example (tested with two other bugs)
* go to the "add comment" box
* type or paste a long text (say, at least 5360 characters, which is long but not that long)
* click on "Add attachment or patch" link below box

Expected:

* new page appears, with same text for further edit, offers to select file to upload

Observed:

* with text size between something between a lower threshold and a higher threshold, server replies with : "400 Bad request
Your browser sent an invalid request. "
* with text size above a higher threshold, server replies with: "Request-URI Too Large - The requested URL's length exceeds the capacity limit for this server. - Apache/2.2.14 (Ubuntu) Server at api.launchpad.net Port 443"

Here are some hints about the thresholds:

du * -b | sort -n | awk '{ print $2 }' | xargs wc --bytes

 4720 this_works.txt
 5360 this_causes_error_400_also.txt
 5680 this_causes_error_400.txt
 6000 this_causes_request_uri_too_large.txt
12000 this_causes_request_uri_too_large_also.txt

* Additional information

Of course, useful comments are generally short.
If comment is long, then probably it contains copy-pasted parts (e.g. logs) that may be better as attachment.

Indeed, Launchpad has an automatic fix when a long comment has no attachment : when submitting it effectively becomes a truncated comment with a full comment downloadable. That fix works very well if the user pressed "add attachment" *before* typing the long text, not in the reverse order.

First clicking "add attachment" then adding an attachment and a long comment text works (and make it a truncated comment with correct attachment and full comment downloadable).

So the only problematic case is typing first a long text then pressing "Add attachment or patch".

* Suggested technical fix

When following "Add attachment or patch" link, do not provide comment text as URL GET parameter but as POST content which will not trigger the web server limitation on URL size.

[Stéphane Gourichon (stephane-gourichon-lpad)]

Firefox developer console make explicit the HTTP error codes returned by server and confirms that the problem lies with long GET URLs (several kilobytes with escaped comment text in URL).

[HTTP/1.1 400 Bad request 302ms]
[HTTP/1.1 414 Request-URI Too Large 230ms]

[Bryan Quigley (bryanquigley)]

Confirmed both errors are reproducible at present (and in staging)