Question

This is the most peculiar thing.

It is from an old in house CMS.

When I attempt to submit my changes, it prompts to save the file linked in the action attribute of the form.

Headers

Request

POST /~site/edit/articles/article_save.php?id=54 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://example.com
Content-Type: multipart/form-data; boundary=---------------------------10102754414578508781458777923
Content-Length: 940
-----------------------------10102754414578508781458777923
Content-Disposition: form-data; name="title"

Home Content
-----------------------------10102754414578508781458777923
Content-Disposition: form-data; name="catid"

18
-----------------------------10102754414578508781458777923
Content-Disposition: form-data; name="activecheck"

1
-----------------------------10102754414578508781458777923
Content-Disposition: form-data; name="image"


-----------------------------10102754414578508781458777923
Content-Disposition: form-data; name="contentWidgToolbarSelectBlock"

<p>
-----------------------------10102754414578508781458777923
Content-Disposition: form-data; name="content"

<p>Edit your article in this text box.</p>
-----------------------------10102754414578508781458777923
Content-Disposition: form-data; name="contentWidgEditor"

true
-----------------------------10102754414578508781458777923--

Response

HTTP/0.9 200 OK

And then Firefox shows….

_{(source: alexanderdickson.com)}

I can’t determine from the response headers as to why this is prompting to open/save. It has always worked. All other PHP files on the site work fine.

Anyone have a clue?

Thanks

Update

Apparently, it just crashes Safari.

I added an image to the CMS article and for some unbeknown reason, it saved correctly. I can not explain why.

Answer 1

It would seem that the web server believes that your request is not an HTTP/1.0+ request, so falling back to prehistoric HTTP/0.9, from back before there were headers to worry about.

Consequently it returns an HTTP/0.9 response. There’s no Content-Type header in an HTTP/0.9 response, so the browser doesn’t know what type of file it’s getting back, so it treats it as application/octet-stream and prompts to save.

How is the request being generated, and how are you inspecting it? Because this looks suspicious:

Content-Length: 940
-----------------------------10102754414578508781458777923

There should be another newline between those two lines. A double-newline is necessary to signify the end of the headers.

(Problems like this can also occur because something Windowsy along the line is eating CRLF sequences and turning them into plain LF newlines, preventing them from working as HTTP/MIME line endings.)