We're working with a third party application that was sending us small XML files via HTTP post requests, which we were handling in a doPost() method of our servlet. They have decided to change it to a GET request. They claim that the XML won't be a parameter, it will still be in the body of the request, just as if it were a POST. I say they're insane. A GET request doesn't have a content body. Who's right?
Second question, if I do try to read the content body in the doGet() method, is it going to work?
What you are saying is a bit confusing as I'm not quite clear on who's initiating the request.
If you are making the GET request to them, the response body can contain the XML. Whether your request is a POST or a GET is immaterial and only affects the format of the request, not the response.
On the other hand, if they are sending you the XML by initiating a request, then yes, a GET request has no body. [ June 20, 2007: Message edited by: Bear Bibeault ]
Yes, they are sending the HTTP request. It used to be a POST request, so sending an XML file made sense. They have now changed it to a GET request, and swear the XML is stored in the content body of the request. Weird, huh?
Yep, I put a sniffer on, and damned if that's not what they're doing.
They swear they're building this with a commercial HTTP class library, as opposed to say writing to the socket. I guess I'll just see if I can parse it with the servlet libraries. It's not legal HTTP though, right? The RFC is somewhat vague on this point. I'd like to send them something authoritative to prove they're violating the protocol.
I don't think that the request body is read until a method such as getParameter is called. So you should be able to read the body. I'd be surprised if there was any code to prevent it.
But it is a whacky thing to do, so who knows.
What's their reasoning behind subverting the HTTP protocol to use GET?
The initiation for request is just begining when the method "getParamet" was executed.So in J2EE system,if you want to handle the request_stream by yourself the only thing that you can do is those that developing a filter for handling when your request is send by post method.You need not to handle when it is get method
If the context type is text/xml then you wouldn't use getParameter anyway. You would need to use getInputStream or getReader.
I won't even guess whether or not a GET request type will cause you problems. The best you can hope for when relying on non-spec compliant behavior is unpredictability. It may work on one server and not work another (or a differernt release of the same server). You'll have to test on each container that you plan to support..
Bear's question is still the most valid. Why would they do that? [ June 21, 2007: Message edited by: Ben Souther ]
Well, so far it's working on Weblogic 8.1, which is our current platform. I can simply call doPost() from doGet() and read the content body as I would from a POST. Essentially they are sending me a POST request, just with the word POST misspelled as GET.
Why are they doing that? They told me it was so they could make the request synchronous, and be able to handle error conditions ... which makes no sense, right? They say that's a function of their class libraries. The GET request is implemented as a call/response while the POST request is set up as an asynchronous broadcast, and event handlers have to be defined to handle the response. I'm skeptical, but what can I do? At least I can get it to work for now.
Originally posted by wang godman: I think you must use ajax thing for synchronization things ,if you do ,you can set it when you use ajax to send a ajax request.
AJAX will ultimately make HTTP get or POST requests.
Post by:autobot
The moustache of a titan! The ad of a flea:
a bit of art, as a gift, the permaculture playing cards