cURL / Mailing Lists / curl-users / Single Mail


RE: Problem with --continue-at

From: Roth, Kevin P. <>
Date: Thu, 22 May 2003 07:57:04 -0400

If there aren't any other messages being printed within the response headers, I don't think I'd start a precedent with this one. Besides, having it mixed in with the headers makes it a little harder to pick out (visually).

How about:

--- start ---
< HTTP/1.1 301 Moved Permanently
Date: Thu, 22 May 2003 06:50:07 GMT
Server: Apache/1.3.26 (Unix)
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
* Location header found, but not followed (see -L option)

<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?)

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

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

4. There's a blank line between the headers and the body.
   The HTTP protocol uses this blank line also, and I think
   it looks better this a little more visual separation.
   You could probably remove the blank line between the
   request and the response headers, since there aren't
   any other blank lines within the rest of the curl output.

Also, I noticed the behavior when using "curl -vi ..." is

  < 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?

- Kevin

This 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.
Received on 2003-05-22