Accessing response headers with a http 401 error

[Andreone]

Hi,

I'm trying to build an application that consumes a rest server
(MongoDB). The server authentication method is based on Digest access
authentication (http://en.wikipedia.org/wiki/
Digest_access_authentication).
This means that authentication information must be set in the
'Authorization' field of the request's header. In order to do that, I
need to perform a first request that fails (401 error), grab some info
from the response like 'realm', 'nonce' and 'qop' values from the 'WWW-
Authenticate' header field.
With these information, I can then build a valid digest authentication
header with my credentials and then send a second request that will
succeed.

My issue is that I can't access the header fields nor the body from
the first response because has soon as I try to access them, cpp-
netlib throw an exception with the message 'Invalid status part'.
When I activate cpp-netlib debug outputs (with BOOST_NETWORK_DEBUG), I
can see the date I'm interested in being dumped to the console:
[DEBUG c:\dev\cpp_default\lib\cpp-netlib\boost\network\protocol\http
\client\connection\async_protocol_handler.hpp:176]: [parser:10] buffer
contents: "401\r\nWWW-Authenticate: Digest realm="mongo", nonce="xxx",
algorithm=MD5, qop="auth" \r\nContent-Type: text/plain\r\nConnection:
close\r\nContent-Length: 12\r\n\r\nnot allowed\n"

How can I access them without causing an exception?

Thank you

Note: I'm using the latest cpp-netlib (0.9.4) with VC++ 10 and boost
1.47.

[Dean Michael Berris]

Here's the problem here: MongoDB is sending an invalid HTTP Status
line in its response. It should give a status message and the version
of the HTTP response. It should read:

HTTP/1.1 401 Unauthorized\r\n

I would say this is "working as intended". I don't see anything in the
HTTP/1.1 RFC that says the HTTP version, status, and status message
are optional in the response. If you can point me to it, I can take
that into consideration and fix the implementation.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1

Cheers

--
Dean Michael Berris
Technical Solutions Engineer
Google

[Andreone]

Thanks for the response. Although I don't know what to do next. I'm
supposed to mimic a C# client and .Net http client seems to ignore
such malformed responses.

Would you consider acceptable to expose the raw response text, even if
its malformed, through a getter? I could then parse the text myself.

Just one thought: I'm wondering if it's a good idea to expect every
server to be fully compliant with the rfc. In a perfect world, it
could be a correct assumption. But if it's not the case, the library
won't be usable with lot web servers. Maybe that the reason (or one of
many) why .Net implementation is permissive.


On May 21, 6:25 am, Dean Michael Berris <dber...@google.com> wrote:

[Glyn Matthews]

Andreone, Dean,

On 21 May 2012 10:01, Andreone <nfau...@gmail.com> wrote:

Thanks for the response. Although I don't know what to do next. I'm
supposed to mimic a C# client and .Net http client seems to ignore
such malformed responses.

Would you consider acceptable to expose the raw response text, even if
its malformed, through a getter? I could then parse the text myself.

Just one thought: I'm wondering if it's a good idea to expect every
server to be fully compliant with the rfc. In a perfect world, it
could be a correct assumption. But if it's not the case, the library
won't be usable with lot web servers. Maybe that the reason (or one of
many) why .Net implementation is permissive.

FWIW, I am inclined to agree with Andreone.  We can conform as closely as we like to the correct standards, but it would be at the expense of interoperability.

Glyn

 

[Dean Michael Berris]

Let me think about it a little more.

I think there should be a way to configure the client in "permissive"
mode which tolerates these incompatibilities making it explicit
instead of implicit. With the refactored client implementation I'm
inclined to support this if someone else would like to work on it.