curl-users
RE: Problem with --continue-at
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)
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?)
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
uniform.
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
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?
- Kevin
-------------------------------------------------------
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