none
HttpSendRequest issue RRS feed

  • Question

  • I have connections to two (unrelated) webservices; both are accessed using POST requests passing a JSON string.

    uisng this code:

    Create a session (InternetOpen)
    Connect to server on given port  (InternetConnect) (either secured or not)
    Create a request on the connection, POST a script (HttpOpenRequest)
    In a loop: Look for options (InternetQueryOptions) to set flags; Set options when instructed until this os Ok.
    Once Ok: in a loop
      Send request (HtpRequest) sending the JSON string.
      Get last error.
      Set security if requested, handle other errors.
    until send Ok of some error has occured in processing.
    If sending was Ok, get the return data (InternetReadFile)

    One site fails in httpSendRequest, stepping through the code with a sniffer running in parallel, I see:

    POST the request, returns status 200
    GET (I guess status) returning status 400: with this error tekst.

    and it looks as if the data is not accepted by the service.

    However. getLastError returns 0.

    The sniffer shows the following output on executing ONLY the httpenRequest call: (data obscured, but all valid)

    POST <URL> HTTP/1.1
    Content-Type: application/json
    User-Agent: (MyConnector)
    Host:<Remote host>:<port>
    Content-Length: 21604
    Pragma: no-cache

    {
    (JSON string)
    }

    HTTP/1.1 301 MOVED PERMANENTLY
    Date: Tue, 09 Sep 2014 15:38:31 GMT
    Server: Apache/2.2.22 (Ubuntu)
    Expires: Tue, 09 Sep 2014 15:38:31 GMT
    Cache-Control: no-cache, no-store, must-revalidate, max-age=0
    Last-Modified: Tue, 09 Sep 2014 15:38:31 GMT
    Location: <URL>
    Vary: Accept-Encoding
    Content-Length: 0
    Content-Type: text/html; charset=utf-8

     

    ------------------------------------------------------------------
    GET <URL> HTTP/1.1
    User-Agent: MyConnector
    Host: :<Remote host>:<port>
    Pragma: no-cache
    Connection: Keep-Alive


    HTTP/1.1 400 BAD REQUEST
    Date: Tue, 09 Sep 2014 15:38:31 GMT
    Server: Apache/2.2.22 (Ubuntu)
    Cache-Control: no-cache, no-store, must-revalidate, max-age=0
    Vary: Cookie,Accept-Encoding
    Expires: Tue, 09 Sep 2014 15:38:31 GMT
    Last-Modified: Tue, 09 Sep 2014 15:38:31 GMT
    Content-Length: 34
    Connection: close
    Content-Type: text/html; charset=utf-8

    Only http POST method is accepted.

    ------------------------------------------------------------------

    and getLastEroro was not yet called.

    Is this 'normal' behaviour, and if so, is there a way to suppress this GET? It _may_ cause the service to abort processing of incoming data.

    The weird thing is it has worked; the database of the service contains data that can only be entered using this interface!

    (As far as it is relevant: The application is developed unsing Dephi 2007 on a Windows XP professional system, originally tested (and working) on Windows 8 Professional (64-bit) where it all worked fine. No changes in the code on either sides (Mine hasn't, the other side tells me they didn't change a thing either)

    Tuesday, September 9, 2014 3:52 PM

Answers

  • The excessive GET is caused by the HTTP 301 directive. It seems like your code is using something like Response.Redirect() somewhere after you've emitted your JSON payload.

    Try insert Response.End() or equivalent after your last write call of JSON content and see if it fixes your bug. (I say equivalent because the server header indicates it's Ubuntu Apache, so the JSON content may not emitted by .NET websites)

    IMO your JSON emitting function is considered buggy because a POST request shall not automatically redirect as stated in RFC 2616 Section 10.3.2. The code shouldn't contain any code path that emits HTTP 301 in the first place.

    Also, just processing the latter HTTP 400 payload is the correct behavior.


    Wednesday, September 10, 2014 2:46 AM
    Answerer

All replies

  • The excessive GET is caused by the HTTP 301 directive. It seems like your code is using something like Response.Redirect() somewhere after you've emitted your JSON payload.

    Try insert Response.End() or equivalent after your last write call of JSON content and see if it fixes your bug. (I say equivalent because the server header indicates it's Ubuntu Apache, so the JSON content may not emitted by .NET websites)

    IMO your JSON emitting function is considered buggy because a POST request shall not automatically redirect as stated in RFC 2616 Section 10.3.2. The code shouldn't contain any code path that emits HTTP 301 in the first place.

    Also, just processing the latter HTTP 400 payload is the correct behavior.


    Wednesday, September 10, 2014 2:46 AM
    Answerer
  • Not the exact answer but it pointed me to another track.

    Thinking of how apache may have been configured, I took a closer look and it turned out the script in the URL didn't end with "/", causing the server to tell the sender that this script is "moved" - to a script that does end in "/" . I added this in the code and behold - the GET was gone

    I run into another issue now, but that is another story.

    Wednesday, September 10, 2014 7:17 AM