locked
HTTP - WinHttp/WebIO cannot parse server response RRS feed

  • Question

  • Hi,

    I have been debugging a problem we have with a client application written in C++ which uses WinHttp.

    This issue is that when we connect to the server using HTTPS, WinHttp always returns error code 12152 "The server response cannot be parsed." exactly on the same request every time. We are also using digest authentication on top of HTTPS and it will always fail on the 401 response of the same request. We happen to be communicating through a protocol over HTTP, and this is the always the second call we make after establishing a new connection, if that matters.

    Connect

    Get -> 401

    Get -> 200OK

    Get -> 401 !ERROR!

    I had to use netsh trace in this scenario because the key exchange algorithm used is Diffie-Hellman. From what I can see, the HTTP seems valid and the 401 response seems identical to the first one.

    That being said, I see in the Microsoft_Windows_WebIO module that we are getting an error on WebHttpReceiveEntityBody Inline Completion: "Error: The specified server cannot perform the requested operation." I don't know under what circumstances this error will appear, so I would like some more information about this if possible.

    This is right after we queue the WinHttp work item, which I assume contains the 12152 error we get in our code.

    The connection is then closed.

    There is another error on HTTP Parser Complete: "Error Overlapped I/O operation is in progress. (0x3E5)". This error also appears in the first 401 response parsing, which ends up being successful.


    I also would like to send the traces, if I can.

    Thanks for your input

    Thursday, February 1, 2018 9:27 PM

All replies

  • I'm facing the same issue, also following a 401/200/xxx series of responses.  For a while it seemed I was able to make the error go away by preemptively providing the authentication credentials on the third request (which in my case is PROPFIND, so that the "xxx" would be a 207) but now it's happening consistently on that third call.

    With 'netsh' and Message Analyzer I can see there is a difference on that last response; for whatever reason I'm getting '0D 0A' terminating my 401 response Status Line; then a '20 0D 0A' terminating the 200 response Status Line; but then a '0D 0D 0A' terminating the final 207.  I can verify that this is the case by using 'curl' on the command line.  So that most likely is the error that WinHTTP is complaining about.

    I did find a posting with an almost identical issue using PROPFIND on SabreDAV (which is in fact the server I'm trying to reach).  So the error is legit.

    Unfortunately, WinHttpSetOption(WINHTTP_OPTION_UNSAFE_HEADER_PARSING) doesn't seem to fix it for me; so I'm still struggling to find a workaround.

    Friday, September 28, 2018 5:19 AM