It supports HTTP/1.0 pretty well now (I think). I'll have to wait and
see what browsers start supporting before I add many more features in this
area. I've updated the docs quite a bit (since the insides changed some).
I think it's a lot cleaner now plus I've fixed quite a few hidden bugs.
I moved a bunch of config options into the config file (things had crept
back into the source over time). Right now it ignores Accept: and
Accept-Encoding: because the browsers I've seen so far don't send
this information correctly.
Here is an example 1.0 reply header from Plexus 2.1:
HTTP/1.0 200 Document follows
Date: Monday, 24-May-93 00:49:16 GMT
Server: plexus/2.1
MIME-version: 1.0
Last-modified: Sunday, 23-May-93 20:42:02 GMT
Content-type: text/html
Which brings up the question of Date format. The Date format you see is
RFC850 (as specified by the current HTTP spec). Any reason we aren't
using RFC822 as modified by RFC 1123 format that MIME specifies for it's
dates (Mon, 24 May 1993 00:49:16 +0000)?
What are you browser writers thinking about supporting wrt HTTP/1.0 request
headers (e.g., see the kerberos proposal below)? We need to think about
how to implement the ChargeTo: and Authorization: headers in a generic
way so the browser can easily support different styles. I would
like to see From:, User-Agent:, and Referer: being used (currently
I've only seen "Accept: text/plain" and "Authorization: user xxx").
If the browser just forked an external program with it's stdout pointing
to the network and let it send whatever headers it needed that might work
(what arguments would it need? maybe just the URL). However, this might be
too inefficient. I think the right way to do it is build the
browser on top of some extensible language (lisp, tcl, forth)
but that's not always an option.
I'll probably be doing another release in the near future (hopefully with
the kerberos stuff mostly done). Here is my current proposal for the
kerberos additions, the XXX part needs work. I haven't figured out what
unique thing to encode and send with each request to verify the client.
Ideas/comments welcome.
--sanders@bsdi.com
---- DRAFT ---- DRAFT ---- DRAFT ---- DRAFT ---- DRAFT ---- DRAFT ----
Proposal for kerberosIV Authentication using HTTP/1.0
I am considering this scheme for adding kerberos authentication to
existing Web software (other ideas are welcome). The purpose of this
proposal is to solicit input from users and browser developers about
what they would like and hopefully to agree on something so that
browser writers can implement it and everyone can start using it.
Steps that require user interaction are marked with a ``*''.
Initial browser-server interaction:
* 1) The user requests a document that is restricted (unknown to her
or the browser).
2) The browser sends the request as currently to the server.
3) The server returns ``402 Payment Required'' with the Cost: field
filled in. For now assume ``Cost: 0''. Also, the server would
return an X-kerberosIV: field with it's Instance@Realm information
e.g., ``X-kerberosIV: web.userid@BSDI.COM''.
* 4) The browser detects the 402 error code and intiates a dialog
containing the information from the Cost: field and requests
the password which is used to authenticate the user in the
servers Realm and get a ticket for the servers Instance.
5) The browser then reissuse the request sending along a header
``Authorization: kerberosIV-1/x-ticket,x-ident''. The x-ticket
and x-indent specify additional headers for the server to check
for the kerberos information. x-ticket: contains an ASCII
encoded ticket for the server; x-ident contains a short message
encrypted with the session key and converted to ASCII (see Note 1).
6) Server verifies client information and sends the requested document.
The Content-encoding: field would be used to specify the document
encoding (if any). X-kerberosIV-safe for authenticated documents or
X-kerberosIV-private for encrypted documents.
Secondary browser-server interaction:
* 7) The user requests a restricted document
8) browser detects server and sends cached authentication information
9) server returns document, unless cached information is invalid then
go back to step 3.
Note 1: This is to prevent message replay.
XXX: What should go in this message? Needs to be unique for each request,
XXX: and encrypted with the session id.
Thanks to Nick Williams for hashing out this idea in email with me.