views:

433

answers:

5

Can an HTTP GET legally contain content? The idea would be to put the request fields in as URL encoded content instead of in the URL to leave the URL clean in a web application for which I am going to be refactoring the resources.

I suspect it's not allowed, but the spec at W3C didn't seem to say.

EDIT: A post is expected to semantically cause backend "writes", and will be prompted to confirm a refresh, which makes it hugely undesirable; it is getting rid of the POSTs which aren't really POSTs while maintaining the current clean URLs that I am shooting for.

EDIT: As someone commented this question is moot (note, not mute), because it will not be possible to get the browser to put query data in the GET content. So my solution is to go with the Post/Redirect/Get suggestion. If I could mark two answers accepted, I would have so marked that one as well as the one I did.

+8  A: 

The GET method does not contain an entity body as defined by RFC2616. The RFC doesn't specifically forbid the inclusion of an entity body, but I suspect that all servers would ignore one for a GET request. Handling a GET request is defined as returning the result of processing the Request URI. It would be arguably wrong to process the Request URI differently based on anything included in the body of a message.

If you want to put the parameters in the body of the message, you should use a POST rather than a GET.

tvanfosson
I'm curious - how would you actually do a GET request from a browser and have it put data in the body? That seems like something you could do with a HTTP client library but not in a browser (without XMLHttpRequest, in which case you don't have to worry about resubmit messages).
Marc Novakowski
Duh! That's a good point. You can't. So that closes this question!
Software Monkey
A: 

I don't believe a body is allowed in a GET request. In any case, it's not likely that it will behave as expected in the presence of proxies.

Tom
+2  A: 

Legally, no, not according to RFC2616. However, theoretically there's nothing stopping you writing your own HTTP handler that would process content in a similar manner to a POST.

EDIT: In reference to another post, admittedly, I hadn't considered proxies. There's a chance that a proxy might strip off the content and you'd lose it, therefore rendering your modification useless...(?)

BenAlabaster
+2  A: 

If your main goal is to avoid the scary "resubmit form" message when a user reloads the page or uses the back button, then you may want to try using the "Post/Redirect/Get" (PRG) pattern.

Marc Novakowski
Yeah, that was what I was thinking I might have to do... +1 for a good suggestion though.
Software Monkey
And here is another situation where I need to be able to accept two answers... yours and tvanfosson's.
Software Monkey
A: 

Based on your edit, it sounds like mod_rewrite (or equivalent) might help you out. You could still have "clean" URIs for the user, but the backend could deal with query strings, etc.

Hank Gay