On Wed, 24 Jan 2007, Shmulik Regev wrote:

> I'm using libcurl to simulate logins to a site that answers a login with a
> 302 (as many do). Instructing libcurl to follow redirects causes libcurl to
> respond to this 302 with a GET, i.e. I get the "Disables POST, goes with
> GET" debug message.
>
> However, the original Content-Length and Content-Type headers are still
> there, and in particular the existence of a non-zero Content-Length causes
> the server to not respond to the request (or so I guess) and the entire
> thing times out. Note that I used the HTTPHEADER option to manually set
> these two fields, hence the custom headers mechanism overrides libcurl's
> default behavior.

When you add them, you add them. libcurl can't possibly know when it should
not use one or more of them just because it follows a redirect.

You probably don't need to set Content-Length by yourself anyway and that is
probably the single header that causes you this grief.

If you really *need* to set them yourself, then I suggest you disable
libcurl's own redirect-magic and imlpement it yourself.

> Currently, I catch the debug info ('Disables POST, goes with GET') and call
> curl_easy_setopt(CURLOPT_HTTPHEADER) with empty Content-Length and
> Content-Type headers to remove them from the GET request. This does the
> trick but seems somewhat kludgey.

I can only agree. If you want to do it this style, you should rather catch the
302 code since that's what triggers that magic in libcurl.

> My question is however, should libcurl automatically strip out these two
> headers (and possibly others) when following redirects and switching from
> POST to GET? If so, where would be the best place to do it?

I don't think it should strip off stuff that was added by the application in
the first place. I would possibly consider a way where the lib would tell the
app about actions so that the app would have a chance to act (differently).
Like for this case, there could be a callback informing the app about the
redir and change of request method or similar. Although it feels like
something that won't be easy to design without it getting weird and klugey.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html