Changelog Development Documentation Download libcurl Mailing Lists News
cURL / Mailing Lists / curl-users / Single Mail

curl-users

RE: Problem with --continue-at

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Thu, 22 May 2003 16:43:48 +0200 (CEST)

On Thu, 22 May 2003, Roth, Kevin P. wrote:

Thanks for your feedback. I think you have valid remarks, but I'll try to
explain why things are like this just now...

> --- start ---
> < HTTP/1.1 301 Moved Permanently
> Date: Thu, 22 May 2003 06:50:07 GMT
> Server: Apache/1.3.26 (Unix)
> Location: https://new.secret.site.domain/
> Transfer-Encoding: chunked
> Content-Type: text/html; charset=iso-8859-1
> * Location header found, but not followed (see -L option)
>
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <HTML><HEAD>
> <TITLE>301 Moved Permanently</TITLE>
> --- end ----
>
>
> Notice a couple of things about this change:
>
> 1. It leads the user to the proper option to enable
> Location: header following (but obviously if they're
> using libcurl, the message should be different?)

To mention command line options, we need to move the "intelligence" to the
client-side code.

I didn't do this because I added my suggested "warning" the laziest possible
way.

> 2. It's at the end of the headers, instead of mixed in

Again, this implies smarter code. Slighly more effort needed.

> 3. I removed the "< " characters from the beginning of the
> response header lines. This makes it more consistent
> with the request headers, where the "> " character is only
> in front of the FIRST line (the GET statement). If you'd
> rather keep the "<"'s on all lines, I'd suggest adding
> ">"'s to all the request header lines too, to make it
> uniform.

The reason for this inconsistency is that libcurl provides the chunks to the
callback like this. When it reads headers from a remote server it provides
them one by one and thus enables us to use a '<' on each header, while when
sending data it provides the entire chunk in one callback message.

Again, this could be "cleaned up" and beautified by the client-side code but
currently isn't.

> Also, I noticed the behavior when using "curl -vi ..." is interesting:
>
> < HTTP/1.1 301 Error
> HTTP/1.1 301 Error
> < Location: /WercsWV/
> Location: /WercsWV/
> < Server: Microsoft-IIS/5.0
> Server: Microsoft-IIS/5.0
> ...
>
> Since many people have been *used* to using -vi in the past, shouldn't we
> be smart enough to realize when these options are both writing to the same
> stream, and skip one of the sets of headers?

I don't think we can do that, as then you couldn't do operations such as

 curl -v -i -o dumpfile

and get the headers to the file as well as in the verbose output. I do in
fact think this new system for the -i option is a lot better than before, as
now you only use -i if you truly want the headers in your output, and adding
-v to the command line doesn't affect the -i'ness. 

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
Received on 2003-05-22