Age | Commit message (Collapse) | Author |
|
HTTP server we return error
|
|
unconditionalliy. Previously, the code check was for >= 300 unless follow-
location was enabled...
|
|
returned an error as there might be stuff in there we must free/cleanup.
This fixes the memory leak Yanick Pelletier posted about 16 Oct 2001
|
|
|
|
|
|
|
|
valid time. we now store the filetime as a long to know for sure it can
hold -1 (there exist some unsigned time_t cases)
|
|
properly match those cookies in subsequent requests
|
|
seriously decreases the amount of used stack space
|
|
|
|
be posted in a minute to the libcurl list.
|
|
NOTE: we might do this for *ALL* errors when doing form posts.
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|