Age | Commit message (Collapse) | Author |
|
1.5.x servers, as they return really screwed up response headers when asked
for with HTTP 1.1.
|
|
|
|
reported 12 Jul 2001)
|
|
afterwards (bug #426442)
|
|
is a FTPS connection as the data transfer is then done unencrypted!
|
|
|
|
strnequal() approach that really didn't follow the RFC properly
|
|
|
|
|
|
|
|
directly after all the headers are received!
|
|
maxdownload set to -1 when not used
|
|
main handle struct to work with persistant connections
|
|
early as possible
|
|
connections were introduced
|
|
- removed #ifdefed code
|
|
|
|
|
|
as an indication of a persistant connection
|
|
|
|
RFC 2616, section 9.4 says: "The HEAD method is identical to GET except that
the server MUST NOT return a message-body in the response."
|
|
|
|
new locations on the same connection that was previously followed on
|
|
|
|
|
|
|
|
|
|
need these at least for debugging 7.7 and probably later as well...
|
|
1.0-reply from a proxy we use and the Proxy-Connection: keep-alive header
is used, we switch it on and live happily ever after
|
|
made it work (partly) with persistant connections for HTTP/1.0 replies
moved the 'newurl' struct field for Location: to the connectdata struct
|
|
as is the case when doing HEAD requests
|
|
|
|
|
|
|
|
intermixed HTTP and FTP persistant connections also work!
|
|
into account
|
|
|
|
|
|
|
|
|
|
will work even when following a Location:
|
|
|
|
GET resume. Other resumes are upload-wise and don't care about this header
in the download stream
|
|
|
|
|
|
|