CODEWITHSUNDEEP
c++cwinapiwinhttp
AFgone
AFgone

Reputation: 1250

Setting useUnsafeHeaderParsing for C++ WinHttp

I'm trying to reach a web page on an embedded device. I'm using WinHttp on Win32. When trying to read response I get error

ERROR_WINHTTP_INVALID_SERVER_RESPONSE 12152 The server response cannot be parsed.

But when I captured with WireShark I can see that response is coming. So to test I wrote a simple C# program. GetResponse was throwing exception

The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF

So according to below solution I set useUnsafeHeaderParsing to true. And it worked fine.

HttpWebRequestError: The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF

Since I can't use C# I need to find a way to set useUnsafeHeaderParsing to true for WinHttp with win32 C++

Many thanks

Upvotes: 0

Views: 839

Answers (2)

Ben Hekster
Ben Hekster

Reputation: 21

Looks like the name of the option must have changed since then: with the current SDK it's WINHTTP_OPTION_UNSAFE_HEADER_PARSING. Also, I verified (by examining the Assembly code directly) that:

  • the option must be DWORD-sized
  • the value of the option doesn't matter, as long as it's nonzero
  • you can only enable unsafe parsing; trying to disable (by setting the option value to zero) causes an error to be returned

Obviously, since this undocumented, it's subject to change.

Upvotes: 0

Lukas Thomsen
Lukas Thomsen

Reputation: 3207

I've briefly looked into the option flags of WinHttpSetOption and found the following entry:

WINHTTP_OPTION_UNSAFE_HEADER_BLOCKING This option is reserved for internal use and should not be called.

Since the option looks linke an on/off switch I would try to do the following:

BOOL bResult;
BOOL bOption = FALSE;

bResult = WinHttpSetOption(hInternet, 
                           WINHTTP_OPTION_UNSAFE_HEADER_BLOCKING,
                           &bOption,
                           sizeof(bOption));
if (bResult == FALSE)
{
    /* handle error with GetLastError() */
}

Well but as MSDN says it's reserved for internal use and therefore the function may change in the future (or has already changed in the past). But it's worth a try... Good Luck!

Upvotes: 1

Related Questions