uploaded attachment isn't downloadable

[Chris Moore]

I attached a patch to bug 29187, but when I tried viewing the attachment the link was bad. The link points to

  http://librarian.launchpad.net/1579734/%22umountroot.patch

(there's a double quote at the front on the filename which I didn't use when uploading).

Clicking the link tells me:

  "
  Content-Type: application/octet-stream

instead of showing the patch I uploaded.

When attaching the patch, I copied the full path to the file I wanted to upload into the clipboard in Emacs, then switched to Firefox and hit control-y in the field for the attachment's path. (control-y is the equivalent of 'paste' in Emacs). Realising my mistake I then hit control-v to paste the path and it seemed to work. Could the control-y have left some invisible character in the input field?

I'll try uploading some attachments here to test it.

[Chris Moore (dooglus)]

I hit control-y in the "attachment (required)" field before hitting control-v and pasting in "/tmp/test1.patch".

[Chris Moore (dooglus)]

This time I didn't hit control-y in the input field, just control-v to paste "/tmp/test2.patch".

[Chris Moore (dooglus)]

It looks like hitting control-y in the attachment input field breaks the upload...

[Chris Moore (dooglus)]

This isn't a problem with Malone, but with Firefox. I'll show how to reproduce it, using attachments...

[Chris Moore (dooglus)]

The attached form can reproduce the problem. Copy a value like "/tmp/file.txt" into the clipboard, then switch to the above form in Firefox and type control-y (which appears to nothing) then control-v (to paste the clipboard contents). Then click the 'add' button.

[Chris Moore (dooglus)]

The above cgi script reveals what is being sent when you click the 'add' button on the previous simple form.

The next 2 attachments will show the output of this script.

[Chris Moore (dooglus)]

In this case I pasted in the filename using just control-v to paste. Everything is as it should be.

[Chris Moore (dooglus)]

In this case I pasted in the filename using just control-v to paste. Everything is as it should be.

The output in the previous attachment was created by typing control-y 'accidentally' just before typing control-v to paste the filename into the input field. I would edit the comment of that attachment if I could.

[Chris Moore (dooglus)]

OK, so I messed up those last 2 attachments. The first is the result of pressing control-y, and the second is without pressing control-y. I guess the moral of the story is "don't press control-y in input fields".

[Chris Moore (dooglus)]

I have been trying to report this upstream, but bugzilla.mozilla.org just hangs when I try to submit the bug report. I've tried it in 3 different browsers with 2 different bugzilla accounts, but they all hang for about 5 minutes and then reply with:

Bad Request
Your browser sent a request that this server could not understand.
Apache/2.0.52 (Red Hat) Server at bugzilla-test.mozilla.org Port 443

The report I was trying to raise was the following, in case anyone else wants to report it upstream:

---------
component
---------

general

----------
user agent
----------

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060210 Ubuntu/dapper Firefox/1.5.0.1

-------
summary
-------

typing control-y into an empty input field invisibly adds \r\n to the end

-------
details
-------

I was using a form like this:

<form action="http://localhost/cgi-bin/foo.cgi" method="post" enctype="multipart/form-data">
<input name="a" type="file" />
<input type="submit" />
</form>

The "file" input expects a filename. I copied a full path into my clipboard using Emacs and wanted to paste it into the "file" input field. I typed control-y, the Emacs way of pasting. Nothing appeared to happen. Realising my mistake I typed control-v instead and the value was pasted. Then I hit submit to send the file for upload, the upload failed.

What got sent to the web server was the following:

-----------------------------11692444882074929047948775071
Content-Disposition: form-data; name="a"; filename="/path/to/file
"
Content-Type: application/octet-stream

-----------------------------11692444882074929047948775071--

Notice the newline at the end of the filename, before the closing quote. The application on the web server interpreted the closing quote and Content-Type header as the contents of the file, and uploaded that.

Using 'get' instead of 'post' causes a similar effect, visiting:

  http://localhost/cgi-bin/foo.cgi?a=file%0D%0A

(note the %0D%0A at the end of the URL).

The same effect happens for regular 'text' input fields, but with less obvious results.

Typing control-y when the field isn't empty doesn't cause this problem.

Typing control-y when the field is empty and then using the 'browse' button to select a file doesn't cause the problem.

------------
to reproduce
------------

1. find a web page which lets you upload a file using an <input type="file">
2. empty the "file" input box if it's not already empty (control-a backspace will do that)
3. type a valid path to a file into the box (don't use the browse button)
4. click 'submit' to upload the file. the file won't be sent to the webserver as it should

[Chris Moore (dooglus)]

But of course, malone screwed up the format of the bug report, removing the newline that firefox put at the end of the filename.

Why does nothing work? Firefox, malone, bugzilla...