Link to home
Start Free TrialLog in
Avatar of mdhq
mdhq

asked on

HTTP Protocol Header; WWW-Authenticate:, Authorize: and Location: !

I've written a HTTP client which generates its own
HTTP-headers.  Now I'm trying to get information from a
site which requires Username and Password.
When contacting the site in "normal manner", I get the
reply:
HTTP/1.1 401 Authorization Required
Date: Mon, 01 Dec 1997 17:33:15 GMT
Server: Apache/1.2.4
WWW-Authenticate: Basic realm="TDN Ajour"
Connection: close
Content-Type: text/html


... so I send back the following reply:
GET http://www.somehost.com/protected-area/ HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.03 [en] (Win95; I)
Authorization: Basic NXjhiehfiiIHFIihfiHIDhdihfIHDIH  
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Content-Type: text/html

... so far so good.  I know that the User:pass is encoded
correctly (PS: the above is just bogus to illustrate),
because I get a new 401 error if I send an invalid username.

But when doing this (sending the correct user:pass),
I get a reply indicating a location change:
HTTP/1.1 302 Moved Temporarily
Date: Mon, 01 Dec 1997 17:34:30 GMT
Server: Apache/1.2.4
Location: http://www.somehost.com/protected/bin2/setuid.pl
Connection: close
Content-Type: text/html

Now I don't know what to do!!!

I've tried sending the same request to the new location URL, that is:
GET http://www.somehost.com/protected/bin2/setuid.pl HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.03 [en] (Win95; I)
Authorization: Basic NXjhiehfiiIHFIihfiHIDhdihfIHDIH  
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Content-Type: text/html

...but get get the reply:
HTTP/1.1 302 Moved Temporarily
Date: Mon, 01 Dec 1997 17:34:30 GMT
Server: Apache/1.2.4
Location: http://www.somehost.com/protected/bin2/error.pl
Connection: close
Content-Type: text/html

When contacting http://www.somehost.com/protected/bin2/error.pl
I get a stupid errormessage back....

(PS: It's not as simple as - like - I've forgotten a CRLF
on the end of each line in the HTTP request, but probably
just some info which I've forgotten to add in the
"relocated" request...)

So - should a "relocation" request contain some additional information
to indicate the document which was *originally* requested?
Or have I missed something else here....


(Additional/summary info which might be helpful...:
 From what I can gather, the server closes down the connection after
 sending back a 401 error.
 I've tried to reconnect to the server using the very socket which
 I was using when I got the 401 error, but that wont work.
 (connect() fails!!?)
 What I'm doing to solve this is:
    1. Issuing a closesocket() on the socket.
    2. Creates a new socket
    3. connects to ther site again.
    4. Sends the same request as before with additional
       Authrize: info...
    5. Gets a 302 errer (temporarily moved)
    6. Step 1-5 at the new location...
    7. Gets a new 302 error a.s.o...    )


This is really messing me up bigtime! :)

So... I'm *really* looking forward to some help on this one!!!!!!

    Regards,
            Eljar Ness


Avatar of mdhq
mdhq

ASKER

If there is some HTTP-tool out there where you can design
a request sequence (headers), it'd help a lot...
(Or maybe I just should write one myself???)

Eljar.
Avatar of mdhq

ASKER

Edited text of question
Avatar of mdhq

ASKER

Edited text of question
hmm... I probably can't give you an answer, but I'll try to help a little anyway: What happens if you connect to that site using Netscape and just enter username&PW in the box? Where do you end up? Does the site also display "Temp. moved"?

I also know that there is some way of monitoring all incoming/outgoing information - maybe I can find out for you. That way you could see exactly Netscape sends and just play copycat :-))
Avatar of mdhq

ASKER

I end up recieving the page which I was requesting!
So obviously, Netscape sends some additional information
which results in correct "relocation"...

If you know of any software (or trick with Netscape) to monitoring out-/incoming info, it'd *really* be great.

Regards,
             mdhq
ASKER CERTIFIED SOLUTION
Avatar of alamo
alamo

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of mdhq

ASKER

Great to run into someone which actually has more experience
than me on this one! :)) Very cool!

Using the socket Spy, which by the way is a GREAT program(!!!),
I discovered that a cookie is sent by *netscape*.
However, I can't find anything about cookies in RFC1945...
(How to design cookies a.s.o. )  
The cookie sent by Netscape is:
  Cookie:.count=6a57a60887e657b60798fa74f3f314b45b156464845505;
  .OMH=252011004446;.count=2 CRLF
....and is sent in the VERY first request to the server.
Which RFC (or other doc) contains the information needed on
how to create unique cookies, and how do *servers* use these cookies?   Are there some code-scheme, and if yes - is there
some source available on this scheme?  
Will all servers store cookies when a client tries to access
protected area?  IF yes:For how long?

Hoping to hear from you in the very near future!!  

    Best regards,
                   mdhq

 

Avatar of mdhq

ASKER

Great to run into someone which actually has more experience
than me on this one! :)) Very cool!

Using the socket Spy, which by the way is a GREAT program(!!!),
I discovered that a cookie is sent by *netscape*.
However, I can't find anything about cookies in RFC1945...
(How to design cookies a.s.o. )  
The cookie sent by Netscape is:
  Cookie:.count=6a57a60887e657b60798fa74f3f314b45b156464845505;
  .OMH=252011004446;.count=2 CRLF
....and is sent in the VERY first request to the server.
Which RFC (or other doc) contains the information needed on
how to create unique cookies, and how do *servers* use these cookies?   Are there some code-scheme, and if yes - is there
some source available on this scheme?  
Will all servers store cookies when a client tries to access
protected area?  IF yes:For how long?

Hoping to hear from you in the very near future!!  

    Best regards,
                   mdhq

 

The way cookies work is that the server sends the cookie to the client as part of the header, and then until the cookie expires (which might be as soon as you close the browser) the client is supposed to send the cookie back to the server on every transaction. Servers often use this to track people. For the moment you can probably get away with sending the exact string you saw NS send.

Netscape invented the cookie, their intro is at http://home.netscape.com/newsref/std/cookie_spec.html. The RFC is at http://www.cis.ohio-state.edu/htbin/rfc/rfc2109.html.

Cookies are somewhat complex - NS botched the implementation in some ways (in my opinion), and Microsoft saw fit to implement them with poorly-documented limitations. There are a bunch of sites out there - start at http://www.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/HTTP/Protocol_Specification/Persistent_Cookies/ and go from there :-)
Avatar of mdhq

ASKER

Are you sure that it's ONLY the server which sends the first
cookie?  Using socketspy, I see that Netscape sends a
cookie in the *very* first request, that is, before any
answer from the server is recieved (I entered the exact URL on
the Location: ... in Netscape)  
Thus - Netscape designed the cookie all by itself ;)  (??)
Anyway - I'll have a looksie at the sites you've suggested.

Again, thanx for good help! :)

Bcnya.

   mdhq



Yes, I am sure - cookies can persist session-to-session and that cookie was probably set the first time you visited the site.

Netscape 4 keeps it's cookies in the file cookies.txt which is in a subdirectory of the Netscape users directory. Find the file and look at it - you'll find the cookie for that site.
Avatar of mdhq

ASKER

Nope.  :)
I deleted the cookies.txt file, and Netscape Communicator still
sends a cookie to all hosts in the *very* first request. (??!!)
Give it a shot with socspy32, and you'll see.

The cookie is, however, "shorter":
Cookie: OMH=252011004446
The count= attribute is excluded for some reason.