On 12/4/06, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Mon, 4 Dec 2006, Dobromir Velev wrote:
>
> > I applied the patch but it doesn't work in this case. cURL tries to send
> the
> > request to the URL in the Location header, but since there is still data
> to
> > read from this connection it will read the content from the first
> request,
>
> Yes, unfortunately that doesn't really surprise me.

Here is the patch which works with my case. It is done against the
7.16.0version

--- transfer.c 2006-12-05 03:22:12.000455040 -0800
+++ transfer.new.c 2006-12-05 03:28:57.431820104 -0800
@@ -1428,6 +1428,14 @@
         k->keepon |= KEEP_WRITE;
       }
     }
+ else if (data->reqdata.newurl && k->size == -1 && !conn->bits.chunk &&
!conn->bits.close){
+ /* Location redirect without Content-length ot Transfer Encoding
headers
+ * Hopefully all data has been read from the connection so we can
stop
+ * waiting for data and continue with the next request.
+ */
+ k->keepon &= ~KEEP_READ;
+ *done = TRUE;
+ }
   }

   if(Curl_pgrsUpdate(conn))

> This is definetely a programming bug on the website, and will be fixed,
> > though it works fine in IE and Firefox. I know you're trying to keep
> cURL
> > RFC compilant and there is no need to deal with such buggy
> implementations.
>
> We break RFCs all over in order to work like the browsers, so if you can
> figure out how they do I certainly wouldn't mind to adapt.
>
> Are you *sure* that the browsers get the very same contents back as you
> get
> with libcurl?

Yes I'm sure - attached is a set of request/response headers obtained using
Live HTP headers on Mozilla Firefox 1.0.7

--
>   Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
>
-- 
Dobromir Velev
---------------------------------------------------------------------------
"Never attribute to malice that which can be
adequately explained by stupidity"