cURL / Mailing Lists / curl-library / Single Mail


Re: bad PUT

From: Daniel Stenberg <>
Date: Mon, 2 Feb 2004 14:17:31 +0100 (CET)

On Fri, 30 Jan 2004, Jacob S wrote:

(The mailing list server is shaky and mails are being dropped and delayed, but
I'm hoping to have that situation sorted within a week or so.)

Thanks for testing my poor attempts and for your very elaborate and accurate

> A client has no idea (nor could it) that a particular server even requires
> authentication to access a resource prior to the initial attempt.

True. But this is irrelevant for us, since we don't know if this is the first
request or not. Typicly when an app provides a user+password to libcurl, it
means it knows it should use authentication to get access to the given

> If the client sends the server a "real" request the first time out the worst
> case scenario is that the server tosses out the request if a client cannot
> provide the right credentials in response to a challenge. Essentially the
> same thing curl would do today except the server would also be tossing out
> the body and not just the header.

You seem to forget something. You claim this server REQUIRES authentication
for a given resource. Now, we send a request to this URL without the proper
credentials, heck, we don't provide any credentials at all. This server still
wants us to pass on data to it. Data that it will refuse to accept since we
can't authenticate. It just seems like a very stupid thing to do.

I figure the right action here is to add an Expect: 100-continue header to the
initial request. It will help us to NOT send away data that isn't accepted,
and still if data will be accepted without the proper credentials we can do
that without making a fuss about it!

Can you try the following patch. It is similar to the previous one, but adds
the 100-continue header to prevent data from being sent until given acceptance
from the server.

    Daniel Stenberg -- --
   [[ Do not send mails to this email address. They won't reach me. ]]

The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.

Received on 2004-02-02