HTTP POST Monitor

Sorry request should be:

POST /hello/ HTTP/1.1\r\nContent-Type: application/xml\r\nAccept-Charset: utf-8\r\nHost: 192.168.1.150\r\nAccept: */*\r\nConnection: Keep-Alive\r\n\r\n \r\n\r\n\r\n\r\n\r\n\r\n\r\n 

In my limited experience, most problems have been formatting, CR/LF. Maybe the final /r/n sequence should be removed. From SOL2167:

 

 

If a request body is specified, precede it with a double \r\n sequence.

 

 

Note: A double \r\n sequence must separate the last header from the request body.

 

 

If the request contains a body, no terminating sequence is required.

 

 

That's a lot of CR/LF's...

 

 

Is there supposed to be any body in there? Your request headers are telling the endpoint that you're sending 110 Bytes of content... But I don't see 110 Bytes of content in the monitor.

 

 

That's the 'Content-Length: 110' bit.

 

 

SOL2167 is basically just telling you that if you're putting a hard-coded string into the monitor, you need to make it look like a REAL HTTP request. So with HTTP/1.1 you have your headers (Separate by CR/LF), then a blank link (The \r\n\r\n sequence) and then the body,

 

 

But you don't have a body in the monitor even though the headers say there should be 110 Bytes of body in there.

 

 

H

Hey

 

 

I'm not a HTTP RFC expert but this does look a bit confusing here cos the first post, as Hamish recognises, has a content-length header but no content, but the second post does have content but no content-length header. AFAIK HTTP1.1 needs a content-length header if there's a body to the POST.

 

 

Perhaps in your second post just remove the body to see if the monitor then works, or at least what error is returned.

 

 

Also, in your second post your body terminates with \r\n\r\n - have you tried without this?

 

 

Hope this helps,

 

N

 

 

Ah. I see the second post now... Joys of taking too much time between reading and replying :)

 

 

The number of CR/LF's in the body of the post should be irrelevant. In fact in XML (Which the body appears to be) they shouldn't even be significant, except to pad out the content to match the 110Bytes...

 

 

WHich makes me think... Have you verified that the post body IS actually 110Bytes in length? It's not longer is it which would cause the post to be passed incomplete to whatever the app was that's handling it.

 

 

H

I make it 98 Bytes... The content-length will actually be on the wire Bytes... So \r and ]n etc and \" will actually be ONE character... Not two...

 

 

H

Thanks for all the replies!

 

 

In the end it was the Content-Length header causing the issue. I found the length by performing a capture and highlighting the body in Wireshark to get an approximation and then adjusting the length till I received the expected response for the monitor. I also noticed that when the Content-Length is excessive, the F5 loops around again on the request and appends x excess bytes to the end of the request - hence I think why there were two HTTP headers in the problematic request. This led me to work to reduce the Content-Length value.