On Oct 17, 2005, at 3:53 PM, Daniel Stenberg wrote:
> You know any details about the server or the specific circumstances
> that makes it do this?

It's a custom ASP application, so the scope is limited to it's users.
The vendor of this application is aware of the issue and have fixed it
in the next version. But rollout of the new version could take some
time. We'd like to support the current users, if we can easily work
around this issue.

> I mean, how likely is it that others will face this same issue with a
> similar setup?

Slim to none, I would guess. :) I'm writing a client for a
client/server protocol that is built on HTTP as the transport protocol.
  This protocol is called RETS, the Real Estate Transaction Standard:

   http://www.rets.org/

I am working on an open source RETS client:

   http://www.crt.realtors.org/projects/rets/librets/

We use libcurl and Expat to do the HTTP and XML heavy lifting. We're
seeing this behavior on one version of one vendor's server
implementation exhibits this behavior. So, I think the scope is fairly
limited, which is why I was proposing to keep the changes private.

> I think the fix would involve detecting that it is a second header
> within the same response. The current logic is written and assumes
> that the second header is from the _next_ response.

Right, that's what I figured. That would be in trasfer.c, correct?
 From what I'm reading, it iterates over all the headers, and if it
finds a WWW-Authenticate header, it forwards it on to
Curl_http_input_auth(). Curl_http_input_auth() has no way of knowing
if it is called multiple times within the same response, so it's got to
be handled

> Thinking about it, I think fixing this in the generic code would make
> sense - as otherwise, as you say, you (the server) can easily "fool"
> libcurl to behave silly by sending it stupid headers. Adding code for
> this would be it more robust.

Well, true. I'm gonna take a day or two to look into this. If I make
some good progress, we're more than happy to contribute the changes
back.

-Dave
Received on 2005-10-18