Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

HTTP 1.1 Header Problem.

88 views
Skip to first unread message

MattStan

unread,
Mar 7, 2003, 6:40:17 AM3/7/03
to
Hi,

I have a problem with my HTTP 1.1 GET request headers. My 1.0 headers
work fine but I am getting intermittent failures with HTTP 1.1. The
headers work with some servers under certain circumstances and not at
all with others. Consider this header:

--------------------------------------------------------------
GET http://www.yahoo.com/index.html HTTP/1.1
Host: www.yahoo.com
Accept: */*
Accept-Language: en-us
Connection: keep-alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

--------------------------------------------------------------

This request to Yahoo works fine when each newline is '\n' but not when
the newlines are '\n\r', this is exactly the reverse of what I would
expect. By the way '\n\r' is: 0A 0D. When '\n\r' is used there is no
response at all from the server.

Something similar happens with www.reuters.co.uk.

--------------------------------------------------------------
GET http://www.reuters.co.uk/ HTTP/1.1
Host: www.reuters.co.uk
Accept: */*
Accept-Language: en-us
Connection: keep-alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

--------------------------------------------------------------

When I use '\n\r' as my newlines I get: 'HTTP/1.1 400 Bad request' but
with just '\n' it works perfectly, I get: 'HTTP/1.1 200 OK'. (Obviously
these were followed by the rest of the header and the body as well in
the case of the latter.

Exactly the same responses as reuters gave are given by
www.yourdictionary.com - the same header was sent except for the server
address.

However www.google.com does not respond to the following header at all
regardless of whether '\n\r' or '\n' is used. That's a NO RESPONSE not a
'HTTP/1.1 400 Bad request' response.

--------------------------------------------------------------
GET http://www.google.com/ HTTP/1.1
Host: www.google.com
Accept: */*
Accept-Language: en-us
Connection: keep-alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

--------------------------------------------------------------

Please can someone enlighten me as to what I am doing wrong?

Thanks and regards from a very confused newcomer to HTTP programming,

..matthew

PS. Sorry if this post is not necessarily strictly relevent to all these
groups, it seems semi-relevent to all of them and unfortunately there is
no such group as comp.protocols.http.

John Gordon

unread,
Mar 7, 2003, 9:17:29 AM3/7/03
to
MattStan <matt...@blueyonder.co.uk> writes:

> GET http://www.yahoo.com/index.html HTTP/1.1

i don't think this is a correct GET statement. the
"http://www.yahoo.com" part isn't supposed to be there. it should
look like this instead:

GET /index.html HTTP/1.1

the remote hostname and port are specified in the connection; there's
no need for them in the GET.

---
John Gordon "No Silicon Heaven? Preposterous! Where would
gor...@jtan.com all the calculators go?" -- Kryten, Red Dwarf

William Park

unread,
Mar 7, 2003, 12:17:08 PM3/7/03
to
In comp.unix.programmer MattStan <matt...@blueyonder.co.uk> wrote:
> Hi,
>
> I have a problem with my HTTP 1.1 GET request headers. My 1.0 headers
> work fine but I am getting intermittent failures with HTTP 1.1. The
> headers work with some servers under certain circumstances and not at
> all with others. Consider this header:
>
> --------------------------------------------------------------
> GET http://www.yahoo.com/index.html HTTP/1.1
> Host: www.yahoo.com

I think that format is only for proxy. For the original server, it
should be
GET /index.html HTTP/1.1
Host: www.yahoo.com

>
> This request to Yahoo works fine when each newline is '\n' but not when
> the newlines are '\n\r', this is exactly the reverse of what I would
> expect. By the way '\n\r' is: 0A 0D. When '\n\r' is used there is no
> response at all from the server.

Spec say '\r\n' is EOL.

--
William Park, Open Geometry Consulting, <openge...@yahoo.ca>
Linux solution for data management and processing.

MattStan

unread,
Mar 7, 2003, 12:29:50 PM3/7/03
to
> >GET http://www.yahoo.com/index.html HTTP/1.1
>
>
> i don't think this is a correct GET statement. the
> "http://www.yahoo.com" part isn't supposed to be there. it should
> look like this instead:
>
> GET /index.html HTTP/1.1
>
> the remote hostname and port are specified in the connection; there's
> no need for them in the GET.

Thanks John, but this does not work either :(

Regards,

..matthew

MattStan

unread,
Mar 7, 2003, 12:33:46 PM3/7/03
to
>>I have a problem with my HTTP 1.1 GET request headers. My 1.0 headers
>>work fine but I am getting intermittent failures with HTTP 1.1. The
>>headers work with some servers under certain circumstances and not at
>>all with others. Consider this header:
>>
>>--------------------------------------------------------------
>>GET http://www.yahoo.com/index.html HTTP/1.1
>>Host: www.yahoo.com
>
>
> I think that format is only for proxy. For the original server, it
> should be
> GET /index.html HTTP/1.1
> Host: www.yahoo.com

Thanks, but this also does not work with the problem servers. :(

>>This request to Yahoo works fine when each newline is '\n' but not when
>>the newlines are '\n\r', this is exactly the reverse of what I would
>>expect. By the way '\n\r' is: 0A 0D. When '\n\r' is used there is no
>>response at all from the server.
>
>
> Spec say '\r\n' is EOL.

Sorry, I forgot to say, I'd already tried this and it still does not work
even with the ammended GET and HOST headers.

Could there be a charcter encoding problem? I'm using ASCII.

Cheers,

..matthew

William Park

unread,
Mar 7, 2003, 1:37:23 PM3/7/03
to
In comp.unix.programmer MattStan <mattstan--...@blueyonder.co.uk> wrote:
>> I think that format is only for proxy. For the original server, it
>> should be
>> GET /index.html HTTP/1.1
>> Host: www.yahoo.com
>
> Thanks, but this also does not work with the problem servers. :(

>> Spec say '\r\n' is EOL.


>
> Sorry, I forgot to say, I'd already tried this and it still does not
> work even with the ammended GET and HOST headers.
>
> Could there be a charcter encoding problem? I'm using ASCII.

Well,
GET /index.html HTTP/1.1\r\n
Host: www.yahoo.com\r\n
\r\n
works for me here.

Phil Frisbie, Jr.

unread,
Mar 7, 2003, 1:53:41 PM3/7/03
to
MattStan wrote:
>> Spec say '\r\n' is EOL.
>
>
> Sorry, I forgot to say, I'd already tried this and it still does not
> work even with the ammended GET and HOST headers.

You are, of course, putting an extra \r\n at the end, right?

GET /index.html HTTP/1.1\r\nHost: www.yahoo.com\r\nAccept: */*\r\n\r\n

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

Joachim Ring

unread,
Mar 7, 2003, 2:10:57 PM3/7/03
to
> > GET http://www.yahoo.com/index.html HTTP/1.1
>
> i don't think this is a correct GET statement. the

actually it is, unfortunately for a forward proxy request to get
http://www.yahoo.com/index.html
which is not allowed with most servers and probably not what the op
wanted anyways...

> "http://www.yahoo.com" part isn't supposed to be there. it should
> look like this instead:
>
> GET /index.html HTTP/1.1
>
> the remote hostname and port are specified in the connection; there's
> no need for them in the GET.

in fact HTTP/1.1 requests must have a Location header with the
intended hostname which allows for more than one vhost per ip address.

to op: the correct line seperator as per rfc2616 is CR LF (0x0d0a) and
not the other way round. plain LF (0x0a aka unix style lineend) is
understood too, but what you used is actually undefined...

joachim

MattStan

unread,
Mar 7, 2003, 3:14:59 PM3/7/03
to
> You are, of course, putting an extra \r\n at the end, right?
>
> GET /index.html HTTP/1.1\r\nHost: www.yahoo.com\r\nAccept: */*\r\n\r\n

Yes -- I sure am.

..matthew

Barry Margolin

unread,
Mar 7, 2003, 3:08:28 PM3/7/03
to
In article <3ae246c1.03030...@posting.google.com>,

Joachim Ring <jr...@web.de> wrote:
>> "http://www.yahoo.com" part isn't supposed to be there. it should
>> look like this instead:
>>
>> GET /index.html HTTP/1.1
>>
>> the remote hostname and port are specified in the connection; there's
>> no need for them in the GET.
>
>in fact HTTP/1.1 requests must have a Location header with the
>intended hostname which allows for more than one vhost per ip address.

Actually, it's a Host header, and the OP had that in his example.

>to op: the correct line seperator as per rfc2616 is CR LF (0x0d0a) and
>not the other way round. plain LF (0x0a aka unix style lineend) is
>understood too, but what you used is actually undefined...

Several respondents have already pointed this out, and the OP said that
this didn't work either. Sounds like you're way behind in the thread.

--
Barry Margolin, barry.m...@level3.com
Genuity Managed Services, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

MattStan

unread,
Mar 7, 2003, 3:27:42 PM3/7/03
to
Hi joachim,


> in fact HTTP/1.1 requests must have a Location header with the
> intended hostname which allows for more than one vhost per ip address.

By this you just mean something like this, right?

> to op: the correct line seperator as per rfc2616 is CR LF (0x0d0a) and
> not the other way round. plain LF (0x0a aka unix style lineend) is
> understood too, but what you used is actually undefined...

I've been trying this with the same results, IE. most servers work fine but
www.google.com and www.zeldman.com (plus more) don't.

My line terminator is:

string nl = "\r\n"; // 0D0A

Any ideas as to why most servers work AOK but some don't? All work fine
with HTTP 1.0.

Thanks and regards,

..matthew

William Park

unread,
Mar 7, 2003, 4:00:34 PM3/7/03
to
In comp.unix.programmer MattStan <mattstan--...@blueyonder.co.uk> wrote:
> By this you just mean something like this, right?
>
> GET http://www.google.com/ HTTP/1.1
> Host: www.google.com

No, something like
GET / HTTP/1.1
Host: www.google.com

>> to op: the correct line seperator as per rfc2616 is CR LF (0x0d0a)
>> and not the other way round. plain LF (0x0a aka unix style lineend)
>> is understood too, but what you used is actually undefined...
>
> I've been trying this with the same results, IE. most servers work fine but
> www.google.com and www.zeldman.com (plus more) don't.
>
> My line terminator is:
>
> string nl = "\r\n"; // 0D0A
>
> Any ideas as to why most servers work AOK but some don't? All work fine
> with HTTP 1.0.

Well,
GET / HTTP/1.0
Host: www.google.com
\r\n
gives me
HTTP/1.1 302 Found
Content-Length: 151
Server: GWS/2.0
Content-Type: text/html
Date: Fri, 07 Mar 2003 20:55:26 GMT
Location: http://www.google.ca/
Set-Cookie:
PREF=ID=2eb7f3a13b4546d6:TM=1047070526:LM=1047070526:S=bIV4HiSTnV2hxxCv;
expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com

<HTML><HEAD><TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.ca/">here</A>.
</BODY></HTML>

So, it works for me, that is, I get a response from the server.

Joachim Ring

unread,
Mar 8, 2003, 5:54:11 AM3/8/03
to
> >> "http://www.yahoo.com" part isn't supposed to be there. it should
> >> look like this instead:
> >>
> >> GET /index.html HTTP/1.1
> >>
> >> the remote hostname and port are specified in the connection; there's
> >> no need for them in the GET.
> >
> >in fact HTTP/1.1 requests must have a Location header with the
> >intended hostname which allows for more than one vhost per ip address.
>
> Actually, it's a Host header, and the OP had that in his example.

right, i always confuse these two - that's why i've got an editor
window with rfc 2616 open all the time at work...



> >to op: the correct line seperator as per rfc2616 is CR LF (0x0d0a) and
> >not the other way round. plain LF (0x0a aka unix style lineend) is
> >understood too, but what you used is actually undefined...
>
> Several respondents have already pointed this out, and the OP said that
> this didn't work either. Sounds like you're way behind in the thread.

hm, seems i need to get a real newsreader again (i've just moved and
switched computers, not all is sorted out yet) as google is obviously
dead slow...

joachim

0 new messages