Forums Register Login

Parsing content body from a GET request

+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
A packet sniffer will show you exactly what's being sent and what isn't.

I like tcpflow on Linux myself but Ethereal has a good reputation among Windows users.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
I think the body of the GET request will simply be ignored.
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
 

Originally posted by Bear Bibeault:
So you should be able to read the body. I'd be surprised if there was any code to prevent it.



The reason I wrote that the body might be ignored is , the body chunk is separated out according to the content-length header value.

So when the request is HTTP GET the container might not even bother to check for content length header and simple ignore the body of the request.
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
So their response to an inadequacy in their library is to subvert the HTTP protocol? I hope your business isn't relying upon them to survive.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
Ajax has no relevance to this issue.
+Pie Number of slices to send: Send
 

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.
The moustache of a titan! The ad of a flea:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 3044 times.
Similar Threads
getReader()
ServletInputStream
REST service accepting XML data
Using different Content Types for REST Webservices
Query about POST request body content
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 12:14:08.