Forum Discussion

mhuss3y_61750's avatar
mhuss3y_61750
Icon for Nimbostratus rankNimbostratus
Jun 04, 2012

HTTP POST Monitor

hi all, i'm stuck with on an issue constructing a HTTP monitor using a POST method. I've created the following monitor to make a POST request for XML content:

 

 

 

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

 

 

 

 

When I use a tool such as wfetch it works fine - I receive a 200 OK, however when using a monitor on the F5 I receive a 500 server or 400 bad request error.

 

 

 

Also I noticed in some request captures two HTTP or Hyper Transfer Protocol headers occur at times. I'm struggling for ideas on why this is occuring on the F5. I'm running version 10.2.0.

 

  • 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.

     

     

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    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
  • nathe's avatar
    nathe
    Icon for Cirrocumulus rankCirrocumulus
    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

     

     

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    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
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    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.