Hi,
According to the firefox source when neither Transfer-encoding or
Content-length headers are set they are just read the content and wait for
the server to close the connection.

from the firefox 2.0 source
netwerk/protocol/http/src/nsHttpTransaction.cpp
lines 896 - 927

  if (mChunkedDecoder) {
  // give the buf over to the chunked decoder so it can reformat the
  // data and tell us how much is really there.
  rv = mChunkedDecoder->HandleChunkedContent(buf, count, contentRead,
contentRemaining);
  if (NS_FAILED(rv)) return rv;
}
else if (mContentLength >= nsInt64(0)) {
  // HTTP/1.0 servers have been known to send erroneous Content-Length
  // headers. So, unless the connection is persistent, we must make
  // allowances for a possibly invalid Content-Length header. Thus, if
  // NOT persistent, we simply accept everything in |buf|.
  if (mConnection->IsPersistent()) {
    nsInt64 remaining = mContentLength - mContentRead;
    nsInt64 count64 = count;
    *contentRead = PR_MIN(count64, remaining);
    *contentRemaining = count - *contentRead;
  }
  else {
    *contentRead = count;
    // mContentLength might need to be increased...
    nsInt64 position = mContentRead + nsInt64(count);
    if (position > mContentLength) {
      mContentLength = position;
      //mResponseHead->SetContentLength(mContentLength);
    }
  }
}
else {
  // when we are just waiting for the server to close the connection...
  // (no explicit content-length given)
  *contentRead = count;
}

I'm now trying to find how they check whether there is more data on the
connection.

Regards
Dobromir Velev

On 12/5/06, Daniel Stenberg <daniel_at_haxx.se > wrote:
>
> On Tue, 5 Dec 2006, Dobromir Velev wrote:
>
> > Here is the patch which works with my case. It is done against the
> > 7.16.0version
>
> ...
>
> > + 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.
> > + */
>
> The "Hopefully" part here is really the key issue I have with this
> approach.
> It is very error-prone and may not even work for your case every time.
>
> So even though I am eager have libcurl work at least as fine as the
> browsers
> on the given input, I would rather see a more reliable and predictable fix
> than this. Sorry.
>
> It would be interesting to know how the Firefox guys have approached this
> problem...
>
> --
> 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"