CGI header behaves differently for forms vs. links

Good morning all,

After a night of reflection, I realized what the problem might be. I have this issue solved, now, but I don't understand my solution.

The basic problem was this: if I used a form-submit button to access a CGI page that used a 'text/plain' HTTP header, the browser wanted to download rather than display. Several monks, having patience with my poor explanations, indicated that it worked fine on their systems.

And, indeed, when I changed the code that called this text-returning CGI script from a form to a link, the browser happily rendered the page.

Apparently, there is something "different" about how a form behaves from a link. So, I checked if this was a GET vs. POST difference, and indeed it is. That surprised me: in my mind GET & POST were basically interchangeable, but POST made a "prettier" URL.

I google'd a bit, and only ran across basic explanations of the GET/POST, nothing that seemed to explain this kind of difference. Can anyone offer any suggestions on where to look to find more information, or on what's going on?

Comment on CGI header behaves differently for forms vs. links

Replies are listed 'Best First'.
Re: CGI header behaves differently for forms vs. links by Anonymous Monk on Sep 10, 2003 at 14:37 UTC
Of course, after I post I find something useful. The important part of this is: The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result. So I suppose the problem is that returning a 'text/plain' stream as the result of a POST is not something that can be identified by a URI. In other words: POST should only return HTML, then?	[reply]

Replies are listed 'Best First'.

Re: CGI header behaves differently for forms vs. links
by Anonymous Monk on Sep 10, 2003 at 14:37 UTC

Of course, after I post I find something useful. The important part of this is:

The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

So I suppose the problem is that returning a 'text/plain' stream as the result of a POST is not something that can be identified by a URI. In other words: POST should only return HTML, then?

[reply]