The HTTP headers and how basic authentication works are well documented features of that protocol.

To use basic authentication what happens is this:

1) you enter </code> http://site1/foo/hello.html

in the browser. This will cause a GET request to be submitted to the webserver at site1. This will request will look something like: 
----------------------------------------- 
GET /foo/hello.html  HTTP/1.0 
 
----------------------------------------- 

2) The webserver gets the request. It determines that it needs a userid and password for this document. It does not see one in the request above (just a GET so far). It will return a document such as: 
 
------------------------------------------- 
Content-Type: text/html 
Status: 401 Unauthorized 
WWW-Authenticate: Basic realm="SomeRealmName" 
 
This document is protected. You must send the proper authorization information 
to access it.  
------------------------------------------- 

3) The browser gets back that document and views the header. it sees the 401 Unauthorized and looks for the WWW-Authenticate line to get the realm. It looks in its little list of REALM=user/passwords it caches in memory (empty right now, we just started the browser). Therefore, it prompts you for the username/password for the realm "SomeRealmName". If you hit cancel right now, it just displays the document (which is "This document is protected. You must send the proper authorization information to access it. ", you've probably seen that before). If you put in a username/pass the browser (MOST browsers anyway) will save the username/password in a list that contains the 

  o realm name 
  o host name requesting the user/pass 
  o port the web server was running on on that host 

The browser then submits a request that looks something like: 
------------------------------------- 
GET /foo/hello.html HTTP/1.0 
Authorization Basic dGt5dGU6dGlnZXI

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

4) the webserver recieves this new request, sees foo needs basic auth, sees the user/pass in the header, verifies it. If the username/password don't match, goto 2 and start over. If it does match the page /foo/hello.html is returned. Assumed it matched. 


5) I now goto 

http://site2/something/else.html

6) I now goto 

http://site1/foo/another_page.html <code>The GET request goes up, the webserver rejects with:
-------------------------------------------
Content-Type: text/html
Status: 401 Unauthorized
WWW-Authenticate: Basic realm="SomeRealmName"

This document is protected. You must send the proper authorization information
to access it.
-------------------------------------------

the browser will take the hostname/portno/someRealmName and look in its little in memory cache. this time it will find it since we just did it a couple of pages ago. It will resend the request with the username and password and we get our page.....

In short, the browser remembers your password for you. It associates a username/passowrd with a HOST, PORT, and REALM. The webserver asks the browser for this information by rejecting the request.....



The username and password are encoded in the HTTP header using a base-64 encoding scheme (a very lightweight encoding scheme, trivial to decode -- email uses this to send binary data in 7 bit ascii format).

If you use SSL (recommended with basic authentication) the entire converstation is encrypted -- including the HTTP headers. That is the answer to question #1 above.

As for number 2 above -- the answer is "no". The browser would have to implement this feature as IT is the one doing the caching of the username/password. There are simply no mechanisms for timing this out in the protocol at all. You would have to ask your browser vendor to offer this feature. There is nothing we can do at the server side to fix this.

as for #3, feel free to follow up with another question but I really don't understand the context of that question. I'm not sure what you are asking about there.