Re: LYNX-DEV two curiosities from IETF HTTP session.

Al Gilman <asgilman@access.digex.net> wrote:
>Two issues came up in today's session of the HTTP 1.1 WG that
>left me curious.  Not that any major decisions hang on the
>answers, but:
>
>Lynx came up when the fellow from MicroSoft quipped regarding the
>305 proxy redirection message "Lynx has implemented it."
>
>Later it appeared he meant to be humorous, as it was left as an
>open question.
>
>The Conventional Wisdom in the meeting is that 305 is broken and
>306 didn't fix it.  The group is headed in the direction that
>this function will not be present in the "Draft Standard" version
>of 1.1.
>
>Going, going...

	The specs for 305 in the most current HTTP/1.1 draft in
effect describe Lynx's implementation, years ago, but not
completely.  Lynx's implementation:

	1) Accepts 305 and acts on the Location: only if a proxy
	   is not already being used, i.e., if it comes from an
	   origin server.  Otherwise, Lynx renders and displays
	   the body.
	2) The redirection is treated as "one time" (a new request
	   for the document will go to the orgin server, not to
	   the proxy of the previous redirection).
	3) The method is retained, and if "unsafe" (POST), the
	   user is prompted whether to proceed.  That is, the
	   redirection is treated like a 307, but with a proxy
	   request structure:
	     http://proxy[:port]/http://origin[:port]/path[;param?query]
	   It would be better to treat it like a 304 (always use GET),
	   IMHO.

This does not serve the originally intended purposes, better reflected
but still imperfect in the 306 draft.  However, it is no less useful
than 304 and 307 (i.e., would not be expected to be used often,
but is available if really needed).   In effect, the origin server
can redirect either to another origin server (304 or 307) or to a
proxy (305) which may have the requested document and, for example,
be closer to the UA.

	If 306 is revised, it would be better to treat that as
a new status, not a revision of 305, and have 306 based on only a
Set-Proxy: header, with no Location header.  Browsers which do not
implement it thus will treat it as 300, and should show the body
by virtue of no Location header being present.

	Whether or not the "guys at MicroSoft" as yet grasp the
occassional uses to which 304, 305, and 307 might be put, they
nonetheless can be useful ocassionally (that statement was intended
to be humorous &#1;).  But 306 does need more work before it's
intended uses can be achieved.

 
>Second point:  CommentURL on cookies.  General tenor of comment
>from commercial implementors was that with excellent orienteering
>skills one would be able to unearth this thing and eventually
>follow it.  Not in any way that was easy or obvious.  I was just
>curious if Lynx would be more aggressive about offering the user
>the option to follow this reference to a discussion of site
>standards for the user of cookies.

	Lynx implements CommentURL as links accessible via the
Cookie Jar.  Apparently, the discussions on the HTTP-WG email
list about this being for descriptions of the particular cookies
which have a CommentURL attribute still have not gotten through.
Since the CommentURL could return text/html, a link to yet another
document which discusses the site's "standards" could be included,
but the document returned via the CommentURL, itself, should
explain how that particular cookie will be used (e.g., to maintain
display preference, or as a shopping cart, or to track retrievals
and offer appropriate "what's new" links within requested documents,
etc.).  The user should be able to make an informed judgment about
whether to suffer the overhead and disk space associated with each,
particular, cookie.  If it's simply "generic" statements about the
site's security/privacy policies, it falls short of servering the
needs of users with respect to cookie management, particularly as
more and more sites set them, and the total number to be handled
and stored would otherwise get rather large (this assumes other
browsers will follow Lynx's lead in offering a substantive cookie
management interface by which users easily can remove particular,
previously or "tentatively" accepted, cookies from the database).

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Tuesday, 9 December 1997 06:51:22 UTC