views:

72

answers:

2

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....

Firefox

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.

+1  A: 

Why is your server returning HTTP/0.9? I dont think that is even valid. It should be at least HTTP/1.0

webdestroya
I have no idea... and the `article_save.php` is a *very* basic file that just saves to a database. The only header it sends is a `Location:` one once the article is saved. Also can not find anything fishy in `.htaccess`
alex
+2  A: 

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.)

bobince
Thanks for the answer Bobince. The request is generated by JavaScript triggering `submit()` on the form, and I am inspecting the headers with the Firefox plugin [Live HTTP Headers](https://addons.mozilla.org/en-US/firefox/addon/3829/), and then saved it to a .txt file on my Mac and copy and pasting into here.
alex
Is there a visual gap between those lines when viewed in Live Headers, that doesn't survive the cut-and-paste? Does `article_save.php` get called at all? If so what `$_SERVER['REQUEST_URI']` does it see?
bobince