From erik@primedata.org Tue Jan  2 10:39:06 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa09410 for <hyper>;
          2 Jan 2001 10:39 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa02177
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 2 Jan 2001 10:38 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id SAA14881;
	Tue, 2 Jan 2001 18:38:12 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA08710;
	Tue, 2 Jan 2001 18:38:11 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id SAA25343; Tue, 2 Jan 2001 18:38:08 GMT
Resent-Date: Tue, 2 Jan 2001 18:38:08 GMT
Message-ID: <190201c074eb$ae87b600$cd4751d1@primedata.org>
From: Erik Aronesty <erik@primedata.org>
To: http-wg@cuckoo.hpl.hp.com
MMDF-Warning:  Parse error in original version of preceding line at poindexter-relay.ics.uci.edu
Subject: Logout
Date: Tue, 2 Jan 2001 13:41:48 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
Disposition-Notification-To: "Erik Aronesty" <erik@primedata.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-MDRemoteIP: 209.81.71.205
X-Return-Path: erik@primedata.org
X-MDaemon-Deliver-To: http-wg@cuckoo.hpl.hp.com
Resent-Message-ID: <"OT1Ib2.0.2A6.R-XKw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/998
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


Dear Sirs,

Is it required that user agents have a mechanism for expiring or forgetting
the passwords that are used to access HTTP servers?  IE: a "logout" button
for HTTP built-in authentication.

I imagine that this is the sort of requirement that HTTP people think that
this should be in the HTML group - and vice-versa.

However it is an embarrassing oversight in modern browsers.


                                - Erik



From dmk@research.bell-labs.com Tue Jan  2 11:19:21 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa11573 for <hyper>;
          2 Jan 2001 11:19 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa12299
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 2 Jan 2001 11:19 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id TAA15702;
	Tue, 2 Jan 2001 19:18:24 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id TAA09731;
	Tue, 2 Jan 2001 19:18:22 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id TAA25518; Tue, 2 Jan 2001 19:18:20 GMT
Resent-Date: Tue, 2 Jan 2001 19:18:20 GMT
Date: Tue, 2 Jan 2001 14:15:42 -0500 (EST)
From: Dave Kristol <dmk@research.bell-labs.com>
Message-Id: <200101021915.OAA21597@aleatory.research.bell-labs.com>
To: erik@primedata.org
Subject: Re: Logout
Cc: http-wg@cuckoo.hpl.hp.com
Resent-Message-ID: <"YGbhB3.0.-D6.8bYKw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/999
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

"Erik Aronesty" <erik@primedata.org> wrote:
  > 
  > Dear Sirs,
  > 
  > Is it required that user agents have a mechanism for expiring or forgetting
  > the passwords that are used to access HTTP servers?  IE: a "logout" button
  > for HTTP built-in authentication.
  > 
  > I imagine that this is the sort of requirement that HTTP people think that
  > this should be in the HTML group - and vice-versa.
  > 
  > However it is an embarrassing oversight in modern browsers.

<sigh>

You have touched on one of *my* hot buttons.  I have argued for such a
thing for, oh, about six years.  Obviously without success.  As you
guess, it's not an HTTP issue, having nothing really to do with the
*protocol*.  But it's also not an HTML issue, having nothing to do with
the content of pages.  Rather it's a user interface issue, and thus at
the discretion of the browser vendors.  And, for whatever reason, they
have never been interested in providing a way to discard passwords,
except to exit the browser.

I can think of two situations where such a feature would be *really*
handy:

1) When I'm trying to debug server-side authentication code, and I want
to force the browser I'm using to forget its passwords.

2) In an environment where machines are shared (college computer lab,
public library, Internet cafe), and I want to discard the passwords
I've entered before I leave the machine.

Similar reasoning would recommend a feature to discard all cookies, as
well, but that's another topic entirely. :-)

Dave Kristol


From jds@mem.net Tue Jan  2 11:48:55 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa13176 for <hyper>;
          2 Jan 2001 11:48 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa19712
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 2 Jan 2001 11:48 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id TAA16310;
	Tue, 2 Jan 2001 19:48:05 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id TAA10481;
	Tue, 2 Jan 2001 19:48:01 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id TAA25755; Tue, 2 Jan 2001 19:47:57 GMT
Resent-Date: Tue, 2 Jan 2001 19:47:57 GMT
Message-ID: <3A522F0E.707D12B@mem.net>
Date: Tue, 02 Jan 2001 13:42:06 -0600
From: Douglas Sims <jds@mem.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Dave Kristol <dmk@research.bell-labs.com>
CC: http-wg@cuckoo.hpl.hp.com
Subject: Re: Logout
References: <200101021915.OAA21597@aleatory.research.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"XyN022.0.wG6.w_YKw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1000
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


I decided several years ago to stop use http authentication and instead use a
similar system with cookies, because http authentication transmits everything in
unencoded form.  I realize that cookies don't provide much better security as the
initial password is going to
be unencoded, but somehow I got some (no doubt misplaced) peace of mind out of
that.

As to your question though, with cookies it's easy enough to just set a cookie with
the same name but a different value.  The new cookie will wipe out the old cookie.

-Doug Sims


Dave Kristol wrote:

> "Erik Aronesty" <erik@primedata.org> wrote:
>   >
>   > Dear Sirs,
>   >
>   > Is it required that user agents have a mechanism for expiring or forgetting
>   > the passwords that are used to access HTTP servers?  IE: a "logout" button
>   > for HTTP built-in authentication.
>   >
>   > I imagine that this is the sort of requirement that HTTP people think that
>   > this should be in the HTML group - and vice-versa.
>   >
>   > However it is an embarrassing oversight in modern browsers.
>
> <sigh>
>
> You have touched on one of *my* hot buttons.  I have argued for such a
> thing for, oh, about six years.  Obviously without success.  As you
> guess, it's not an HTTP issue, having nothing really to do with the
> *protocol*.  But it's also not an HTML issue, having nothing to do with
> the content of pages.  Rather it's a user interface issue, and thus at
> the discretion of the browser vendors.  And, for whatever reason, they
> have never been interested in providing a way to discard passwords,
> except to exit the browser.
>
> I can think of two situations where such a feature would be *really*
> handy:
>
> 1) When I'm trying to debug server-side authentication code, and I want
> to force the browser I'm using to forget its passwords.
>
> 2) In an environment where machines are shared (college computer lab,
> public library, Internet cafe), and I want to discard the passwords
> I've entered before I leave the machine.
>
> Similar reasoning would recommend a feature to discard all cookies, as
> well, but that's another topic entirely. :-)
>
> Dave Kristol


From dmk@bell-labs.com Tue Jan  2 11:57:01 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa13574 for <hyper>;
          2 Jan 2001 11:57 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa21775
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 2 Jan 2001 11:56 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id TAB16513;
	Tue, 2 Jan 2001 19:56:23 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id TAA10725;
	Tue, 2 Jan 2001 19:56:22 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id TAA25890; Tue, 2 Jan 2001 19:56:20 GMT
Resent-Date: Tue, 2 Jan 2001 19:56:20 GMT
Sender: dmk@research.bell-labs.com
Message-ID: <3A52318B.54053E37@bell-labs.com>
Date: Tue, 02 Jan 2001 14:52:43 -0500
From: Dave Kristol <dmk@bell-labs.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Douglas Sims <jds@mem.net>
CC: http-wg@cuckoo.hpl.hp.com
Subject: Re: Logout
References: <200101021915.OAA21597@aleatory.research.bell-labs.com> <3A522F0E.707D12B@mem.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"YZFYX2.0.DJ6.g8ZKw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1001
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

Douglas Sims wrote:
> [...]
> As to your question though, with cookies it's easy enough to just set a cookie with
> the same name but a different value.  The new cookie will wipe out the old cookie.

Yes, that solves the problem from the server's perspective, assuming an
application provides that capability.

But if I'm using a public access machine and I want to ensure that that machine
has removed all the cookies I might have received (including those that might
have been used for personalized services and/or authentication), *I* have no
direct way to do so.

Dave Kristol


From tom@mclaren.tc Tue Jan  2 12:38:55 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa15827 for <hyper>;
          2 Jan 2001 12:38 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa02088
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 2 Jan 2001 12:38 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id UAA17375;
	Tue, 2 Jan 2001 20:38:02 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id UAA11765;
	Tue, 2 Jan 2001 20:38:00 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id UAA26125; Tue, 2 Jan 2001 20:37:58 GMT
Resent-Date: Tue, 2 Jan 2001 20:37:58 GMT
From: Tom McLaren <tom@mclaren.tc>
To: http-wg@cuckoo.hpl.hp.com
MMDF-Warning:  Parse error in original version of preceding line at poindexter-relay.ics.uci.edu
Subject: RE: Logout
Date: Tue, 2 Jan 2001 20:25:26 -0000
Message-ID: <DEEDIPFNGKJGJCCFAMIGAECHCAAA.tom@mclaren.tc>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <DEEDIPFNGKJGJCCFAMIGKECGCAAA.tom@mclaren.tc>
Disposition-Notification-To: "Tom McLaren" <tom@mclaren.tc>
Resent-Message-ID: <"FONah1.0.QN6.wlZKw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1002
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

<apologies for resend>

Excuse me if I'm missing the point, but with IE (my browser of choice),
isn't this addressed by the autocomplete option, esp. the ability to clear
passwords/details? Also, on shared PCs, I find deleting temporary files when
I leave a necessity.

An interesting point raised is whether browser vendors should expose what is
primarily internal functionality to aid the user (e.g. password remembrance)
to external (primarily display only) data. Similar to Java access
permissions? Hmmm ...

-----Original Message-----
From: Dave Kristol [mailto:dmk@research.bell-labs.com]
Sent: 02 January 2001 19:16
To: erik@primedata.org
Cc: http-wg@cuckoo.hpl.hp.com
Subject: Re: Logout


"Erik Aronesty" <erik@primedata.org> wrote:
  >
  > Dear Sirs,
  >
  > Is it required that user agents have a mechanism for expiring or
forgetting
  > the passwords that are used to access HTTP servers?  IE: a "logout"
button
  > for HTTP built-in authentication.
  >
  > I imagine that this is the sort of requirement that HTTP people think
that
  > this should be in the HTML group - and vice-versa.
  >
  > However it is an embarrassing oversight in modern browsers.

<sigh>

You have touched on one of *my* hot buttons.  I have argued for such a
thing for, oh, about six years.  Obviously without success.  As you
guess, it's not an HTTP issue, having nothing really to do with the
*protocol*.  But it's also not an HTML issue, having nothing to do with
the content of pages.  Rather it's a user interface issue, and thus at
the discretion of the browser vendors.  And, for whatever reason, they
have never been interested in providing a way to discard passwords,
except to exit the browser.

I can think of two situations where such a feature would be *really*
handy:

1) When I'm trying to debug server-side authentication code, and I want
to force the browser I'm using to forget its passwords.

2) In an environment where machines are shared (college computer lab,
public library, Internet cafe), and I want to discard the passwords
I've entered before I leave the machine.

Similar reasoning would recommend a feature to discard all cookies, as
well, but that's another topic entirely. :-)

Dave Kristol



From erik@primedata.org Tue Jan  2 13:10:06 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa17301 for <hyper>;
          2 Jan 2001 13:10 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa09761
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 2 Jan 2001 13:09 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id VAA17915;
	Tue, 2 Jan 2001 21:08:56 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id VAA12450;
	Tue, 2 Jan 2001 21:08:54 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id VAA26362; Tue, 2 Jan 2001 21:08:50 GMT
Resent-Date: Tue, 2 Jan 2001 21:08:50 GMT
Message-ID: <197a01c07500$c1ad6530$cd4751d1@primedata.org>
From: Erik Aronesty <erik@primedata.org>
To: Scott Lawrence <slawrence@virata.com>
Cc: http-wg@cuckoo.hpl.hp.com
MMDF-Warning:  Parse error in original version of preceding line at poindexter-relay.ics.uci.edu
References: <190201c074eb$ae87b600$cd4751d1@primedata.org> <3A523633.4020401@virata.com>
Subject: Re: Logout
Date: Tue, 2 Jan 2001 16:12:39 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
Disposition-Notification-To: "Erik Aronesty" <erik@primedata.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-MDRemoteIP: 209.81.71.205
X-Return-Path: erik@primedata.org
X-MDaemon-Deliver-To: http-wg@cuckoo.hpl.hp.com
Resent-Message-ID: <"dB5I4.0.1Q6.cBaKw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1003
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


> > the passwords that are used to access HTTP servers?  IE: a "logout"
button
> > for HTTP built-in authentication.
> >
> > I imagine that this is the sort of requirement that HTTP people think
that
> > this should be in the HTML group - and vice-versa.
> >
> > However it is an embarrassing oversight in modern browsers.
>
> One that some of us have tried hard to overcome, to no avail.  The
> basic problem is that the browser vendors have listened carefully to
> what thier customers want, and have heard loud and clear that they
> don't want to have to remember passwords.

Over 600 users have asked us within the last year how to "log out" of sites
such as etrade and daytek which use HTTP based authentication.

Browser customers don't want to remember passwords - however they want
a "logout button" as well.  This is not a paradox and there is no
inextricable reason why
browsers can't cache usr information but have a button for "clearing the
cache"

I think the real reason that this has not been done is because both major
browsers today have other agendas regarding network access and security.

Currently there is no way to clear the cache by having an HTTP server
request
it to be cleared - or by a user initiating the clearing of this information.
This
is a basic security leak - and should be plugged.

> Paul Leach of Microsoft and I attempted to provide a framework for a
> solution to this and some related problems in a submission to the
> W3C (User Agent Authentication Forms) in February of 1999:
>
>     http://www.w3.org/TR/1999/NOTE-authentform-19990203


However, this is a "forms based" solution which undermines digest
authentication
and other more "standard" forms of authentication - that have proved very
helpful
to developers of web applications.

Simply, there should be one line added to section 4.13

    ftp://ftp.isi.edu/in-notes/rfc2617.txt

"It is reccomended that the authenticating agent provide a set mechanisms
for
removing entries from the "password file" associated with a given realm, for
the purposes of logging out of a system."

And that's about all that's necessary.

I don't think it needs a whole RFC ... just an addendum to existing ones.

            - Erik



From erik@primedata.org Tue Jan  2 13:10:10 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa17316 for <hyper>;
          2 Jan 2001 13:10 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa09832
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 2 Jan 2001 13:10 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id VAA18032;
	Tue, 2 Jan 2001 21:09:12 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id VAA12510;
	Tue, 2 Jan 2001 21:09:06 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id VAA26398; Tue, 2 Jan 2001 21:09:04 GMT
Resent-Date: Tue, 2 Jan 2001 21:09:04 GMT
Message-ID: <198b01c07501$13fa9420$cd4751d1@primedata.org>
From: Erik Aronesty <erik@primedata.org>
To: Erik Aronesty <erik@primedata.org>, 
    Scott Lawrence <slawrence@virata.com>
Cc: http-wg@cuckoo.hpl.hp.com, support@microsoft.com
MMDF-Warning:  Parse error in original version of preceding line at poindexter-relay.ics.uci.edu
Subject: Re: Logout
Date: Tue, 2 Jan 2001 16:15:03 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
Disposition-Notification-To: "Erik Aronesty" <erik@primedata.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-MDRemoteIP: 209.81.71.205
X-Return-Path: erik@primedata.org
X-MDaemon-Deliver-To: http-wg@cuckoo.hpl.hp.com
Resent-Message-ID: <"cuKeJ3.0.7S6.fDaKw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1004
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


Sorry I found it... there is a recommendation,

    Microsoft and Netscape just blindly ignore it:

Section 15.6 "Authentication Credentials and Idle Clients":

 "In particular, user agents which cache credentials are
   encouraged to provide a readily accessible mechanism for discarding
   cached credentials under user control."

Which neither do - even though it's a security hole.

                - Erik

----- Original Message -----
From: "Erik Aronesty" <erik@primedata.org>
To: "Scott Lawrence" <slawrence@virata.com>
Cc: <http-wg@cuckoo.hpl.hp.com>
Sent: Tuesday, January 02, 2001 4:12 PM
Subject: Re: Logout


> > > the passwords that are used to access HTTP servers?  IE: a "logout"
> button
> > > for HTTP built-in authentication.
> > >
> > > I imagine that this is the sort of requirement that HTTP people think
> that
> > > this should be in the HTML group - and vice-versa.
> > >
> > > However it is an embarrassing oversight in modern browsers.
> >
> > One that some of us have tried hard to overcome, to no avail.  The
> > basic problem is that the browser vendors have listened carefully to
> > what thier customers want, and have heard loud and clear that they
> > don't want to have to remember passwords.
>
> Over 600 users have asked us within the last year how to "log out" of
sites
> such as etrade and daytek which use HTTP based authentication.
>
> Browser customers don't want to remember passwords - however they want
> a "logout button" as well.  This is not a paradox and there is no
> inextricable reason why
> browsers can't cache usr information but have a button for "clearing the
> cache"
>
> I think the real reason that this has not been done is because both major
> browsers today have other agendas regarding network access and security.
>
> Currently there is no way to clear the cache by having an HTTP server
> request
> it to be cleared - or by a user initiating the clearing of this
information.
> This
> is a basic security leak - and should be plugged.
>
> > Paul Leach of Microsoft and I attempted to provide a framework for a
> > solution to this and some related problems in a submission to the
> > W3C (User Agent Authentication Forms) in February of 1999:
> >
> >     http://www.w3.org/TR/1999/NOTE-authentform-19990203
>
>
> However, this is a "forms based" solution which undermines digest
> authentication
> and other more "standard" forms of authentication - that have proved very
> helpful
> to developers of web applications.
>
> Simply, there should be one line added to section 4.13
>
>     ftp://ftp.isi.edu/in-notes/rfc2617.txt
>
> "It is reccomended that the authenticating agent provide a set mechanisms
> for
> removing entries from the "password file" associated with a given realm,
for
> the purposes of logging out of a system."
>
> And that's about all that's necessary.
>
> I don't think it needs a whole RFC ... just an addendum to existing ones.
>
>             - Erik
>



From tom@mclaren.tc Wed Jan  3 02:04:37 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa20132 for <hyper>;
          3 Jan 2001 02:04 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa22797
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 3 Jan 2001 02:04 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id KAA00813;
	Wed, 3 Jan 2001 10:02:36 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id KAA17027;
	Wed, 3 Jan 2001 10:02:36 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id KAA07507; Wed, 3 Jan 2001 10:02:25 GMT
Resent-Date: Wed, 3 Jan 2001 10:02:25 GMT
From: Tom McLaren <tom@mclaren.tc>
To: Erik Aronesty <erik@primedata.org>
Cc: http-wg@cuckoo.hpl.hp.com
MMDF-Warning:  Parse error in original version of preceding line at poindexter-relay.ics.uci.edu
Subject: RE: Logout
Date: Wed, 3 Jan 2001 09:47:57 -0000
Message-ID: <DEEDIPFNGKJGJCCFAMIGEECLCAAA.tom@mclaren.tc>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <198b01c07501$13fa9420$cd4751d1@primedata.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Disposition-Notification-To: "Tom McLaren" <tom@mclaren.tc>
Resent-Message-ID: <"FYFoN.0.Oq1.zVlKw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1005
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

I agree that a "logout" type button should certainly be implemented. I'm
interested in your choice of words however, naming the non-provision of an
HTTP server cache clearance request as a security hole. In my opinion it is
the responsibility of the site to provide some form of timeout security. To
provide an HTTP type clearance of the cache is exposing the agent to what
amounts to control by a third party. Surely this would constitute a greater
threat to security and not be a road to wander down without serious
consideration of the potential future implications?

Tom

> -----Original Message-----
> From: Erik Aronesty [mailto:erik@primedata.org]
> Sent: 02 January 2001 21:15
> To: Erik Aronesty; Scott Lawrence
> Cc: http-wg@cuckoo.hpl.hp.com; support@microsoft.com
> Subject: Re: Logout
>
>
>
> Sorry I found it... there is a recommendation,
>
>     Microsoft and Netscape just blindly ignore it:
>
> Section 15.6 "Authentication Credentials and Idle Clients":
>
>  "In particular, user agents which cache credentials are
>    encouraged to provide a readily accessible mechanism for discarding
>    cached credentials under user control."
>
> Which neither do - even though it's a security hole.
>
>                 - Erik
>
> ----- Original Message -----
> From: "Erik Aronesty" <erik@primedata.org>
> To: "Scott Lawrence" <slawrence@virata.com>
> Cc: <http-wg@cuckoo.hpl.hp.com>
> Sent: Tuesday, January 02, 2001 4:12 PM
> Subject: Re: Logout
>
>
> > > > the passwords that are used to access HTTP servers?  IE: a "logout"
> > button
> > > > for HTTP built-in authentication.
> > > >
> > > > I imagine that this is the sort of requirement that HTTP
> people think
> > that
> > > > this should be in the HTML group - and vice-versa.
> > > >
> > > > However it is an embarrassing oversight in modern browsers.
> > >
> > > One that some of us have tried hard to overcome, to no avail.  The
> > > basic problem is that the browser vendors have listened carefully to
> > > what thier customers want, and have heard loud and clear that they
> > > don't want to have to remember passwords.
> >
> > Over 600 users have asked us within the last year how to "log out" of
> sites
> > such as etrade and daytek which use HTTP based authentication.
> >
> > Browser customers don't want to remember passwords - however they want
> > a "logout button" as well.  This is not a paradox and there is no
> > inextricable reason why
> > browsers can't cache usr information but have a button for "clearing the
> > cache"
> >
> > I think the real reason that this has not been done is because
> both major
> > browsers today have other agendas regarding network access and security.
> >
> > Currently there is no way to clear the cache by having an HTTP server
> > request
> > it to be cleared - or by a user initiating the clearing of this
> information.
> > This
> > is a basic security leak - and should be plugged.
> >
> > > Paul Leach of Microsoft and I attempted to provide a framework for a
> > > solution to this and some related problems in a submission to the
> > > W3C (User Agent Authentication Forms) in February of 1999:
> > >
> > >     http://www.w3.org/TR/1999/NOTE-authentform-19990203
> >
> >
> > However, this is a "forms based" solution which undermines digest
> > authentication
> > and other more "standard" forms of authentication - that have
> proved very
> > helpful
> > to developers of web applications.
> >
> > Simply, there should be one line added to section 4.13
> >
> >     ftp://ftp.isi.edu/in-notes/rfc2617.txt
> >
> > "It is reccomended that the authenticating agent provide a set
> mechanisms
> > for
> > removing entries from the "password file" associated with a given realm,
> for
> > the purposes of logging out of a system."
> >
> > And that's about all that's necessary.
> >
> > I don't think it needs a whole RFC ... just an addendum to
> existing ones.
> >
> >             - Erik
> >
>
>
>


From erik@primedata.org Wed Jan  3 08:49:48 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa08192 for <hyper>;
          3 Jan 2001 08:49 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa25515
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 3 Jan 2001 08:49 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id QAA12413;
	Wed, 3 Jan 2001 16:49:09 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA05207;
	Wed, 3 Jan 2001 16:49:08 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id QAA08528; Wed, 3 Jan 2001 16:48:50 GMT
Resent-Date: Wed, 3 Jan 2001 16:48:50 GMT
Message-ID: <1d0f01c075a4$e0c6b8a0$cd4751d1@primedata.org>
From: Erik Aronesty <erik@primedata.org>
To: Tom McLaren <tom@mclaren.tc>
Cc: http-wg@cuckoo.hpl.hp.com
MMDF-Warning:  Parse error in original version of preceding line at poindexter-relay.ics.uci.edu
References: <DEEDIPFNGKJGJCCFAMIGEECLCAAA.tom@mclaren.tc>
Subject: Re: Logout
Date: Wed, 3 Jan 2001 11:47:32 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
Disposition-Notification-To: "Erik Aronesty" <erik@primedata.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-MDRemoteIP: 209.81.71.205
X-Return-Path: erik@primedata.org
X-MDaemon-Deliver-To: http-wg@cuckoo.hpl.hp.com
Resent-Message-ID: <"yXxLt1.0.A32.LQrKw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1006
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


Dear Tom,

The site cannot easily know whether or not the request was coming from the
cache or the client... unless the cache tells it.

Thus the server always relys on a "third party" (the browser or the
cache)... to manage or respect authentication "state".

It's just an oversight that cookies are "expirable" (they have timeouts and
they can be forced by the server to expire) and usernames/passwords aren't.

In a way, "cookies" are "more secure" than the security mechanisms built
into http.

                - Erik

----- Original Message -----
From: "Tom McLaren" <tom@mclaren.tc>
To: "Erik Aronesty" <erik@primedata.org>
Cc: <http-wg@cuckoo.hpl.hp.com>
Sent: Wednesday, January 03, 2001 4:47 AM
Subject: RE: Logout


> I agree that a "logout" type button should certainly be implemented. I'm
> interested in your choice of words however, naming the non-provision of an
> HTTP server cache clearance request as a security hole. In my opinion it
is
> the responsibility of the site to provide some form of timeout security.
To
> provide an HTTP type clearance of the cache is exposing the agent to what
> amounts to control by a third party. Surely this would constitute a
greater
> threat to security and not be a road to wander down without serious
> consideration of the potential future implications?
>
> Tom
>
> > -----Original Message-----
> > From: Erik Aronesty [mailto:erik@primedata.org]
> > Sent: 02 January 2001 21:15
> > To: Erik Aronesty; Scott Lawrence
> > Cc: http-wg@cuckoo.hpl.hp.com; support@microsoft.com
> > Subject: Re: Logout
> >
> >
> >
> > Sorry I found it... there is a recommendation,
> >
> >     Microsoft and Netscape just blindly ignore it:
> >
> > Section 15.6 "Authentication Credentials and Idle Clients":
> >
> >  "In particular, user agents which cache credentials are
> >    encouraged to provide a readily accessible mechanism for discarding
> >    cached credentials under user control."
> >
> > Which neither do - even though it's a security hole.
> >
> >                 - Erik
> >
> > ----- Original Message -----
> > From: "Erik Aronesty" <erik@primedata.org>
> > To: "Scott Lawrence" <slawrence@virata.com>
> > Cc: <http-wg@cuckoo.hpl.hp.com>
> > Sent: Tuesday, January 02, 2001 4:12 PM
> > Subject: Re: Logout
> >
> >
> > > > > the passwords that are used to access HTTP servers?  IE: a
"logout"
> > > button
> > > > > for HTTP built-in authentication.
> > > > >
> > > > > I imagine that this is the sort of requirement that HTTP
> > people think
> > > that
> > > > > this should be in the HTML group - and vice-versa.
> > > > >
> > > > > However it is an embarrassing oversight in modern browsers.
> > > >
> > > > One that some of us have tried hard to overcome, to no avail.  The
> > > > basic problem is that the browser vendors have listened carefully to
> > > > what thier customers want, and have heard loud and clear that they
> > > > don't want to have to remember passwords.
> > >
> > > Over 600 users have asked us within the last year how to "log out" of
> > sites
> > > such as etrade and daytek which use HTTP based authentication.
> > >
> > > Browser customers don't want to remember passwords - however they want
> > > a "logout button" as well.  This is not a paradox and there is no
> > > inextricable reason why
> > > browsers can't cache usr information but have a button for "clearing
the
> > > cache"
> > >
> > > I think the real reason that this has not been done is because
> > both major
> > > browsers today have other agendas regarding network access and
security.
> > >
> > > Currently there is no way to clear the cache by having an HTTP server
> > > request
> > > it to be cleared - or by a user initiating the clearing of this
> > information.
> > > This
> > > is a basic security leak - and should be plugged.
> > >
> > > > Paul Leach of Microsoft and I attempted to provide a framework for a
> > > > solution to this and some related problems in a submission to the
> > > > W3C (User Agent Authentication Forms) in February of 1999:
> > > >
> > > >     http://www.w3.org/TR/1999/NOTE-authentform-19990203
> > >
> > >
> > > However, this is a "forms based" solution which undermines digest
> > > authentication
> > > and other more "standard" forms of authentication - that have
> > proved very
> > > helpful
> > > to developers of web applications.
> > >
> > > Simply, there should be one line added to section 4.13
> > >
> > >     ftp://ftp.isi.edu/in-notes/rfc2617.txt
> > >
> > > "It is reccomended that the authenticating agent provide a set
> > mechanisms
> > > for
> > > removing entries from the "password file" associated with a given
realm,
> > for
> > > the purposes of logging out of a system."
> > >
> > > And that's about all that's necessary.
> > >
> > > I don't think it needs a whole RFC ... just an addendum to
> > existing ones.
> > >
> > >             - Erik
> > >
> >
> >
> >
>
>
>



From dwm@xpasc.com Wed Jan  3 10:16:56 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa22832 for <hyper>;
          3 Jan 2001 10:16 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa14670
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 3 Jan 2001 10:16 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id SAA14813;
	Wed, 3 Jan 2001 18:14:51 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA08297;
	Wed, 3 Jan 2001 18:14:51 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id SAA08904; Wed, 3 Jan 2001 18:14:24 GMT
Resent-Date: Wed, 3 Jan 2001 18:14:24 GMT
Date: Wed, 3 Jan 2001 13:08:58 -0500 (EST)
From: "David W. Morris" <dwm@xpasc.com>
X-Sender:  <dwm@ncal.verio.com>
To: Tom McLaren <tom@mclaren.tc>
cc: Erik Aronesty <erik@primedata.org>, http-wg@cuckoo.hpl.hp.com
MMDF-Warning:  Parse error in original version of preceding line at poindexter-relay.ics.uci.edu
Subject: RE: Logout
In-Reply-To: <DEEDIPFNGKJGJCCFAMIGEECLCAAA.tom@mclaren.tc>
Message-ID: <Pine.GSO.4.30.0101031302490.6544-100000@ncal.verio.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"THPF3.0.R92.ohsKw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1007
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


On Wed, 3 Jan 2001, Tom McLaren wrote:

> I agree that a "logout" type button should certainly be implemented. I'm
> interested in your choice of words however, naming the non-provision of an
> HTTP server cache clearance request as a security hole. In my opinion it is
> the responsibility of the site to provide some form of timeout security. To
> provide an HTTP type clearance of the cache is exposing the agent to what
> amounts to control by a third party. Surely this would constitute a greater
> threat to security and not be a road to wander down without serious
> consideration of the potential future implications?

Any control provided to the server should of course be scoped to the data
'owned' by that server, hence no security exposure. Likewise, it should be
possible for a user to expunge ALL data cached from their session, login
credentials, cookies, pages etc. It should be possible for the 'owner' of
the user agent installation to configure the UA to peform this function
automatically when closed, etc.  Again not a security issue if the action
is performed by or directly on behalf of the human user.

And of course, any well designed web application will implement a timeout
stragegy because they can't trust the other end.  Unfortunately short
timeouts which improve security have the strong potential for very
frustrated users who happen to be interrupted by a phone call or other
task while in the middle of an interaction.


Dave Morris


From dwm@xpasc.com Wed Jan  3 10:22:49 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa23326 for <hyper>;
          3 Jan 2001 10:22 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa15924
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 3 Jan 2001 10:22 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id SAA15169;
	Wed, 3 Jan 2001 18:22:03 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA08592;
	Wed, 3 Jan 2001 18:22:01 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id SAA09057; Wed, 3 Jan 2001 18:21:59 GMT
Resent-Date: Wed, 3 Jan 2001 18:21:59 GMT
Date: Wed, 3 Jan 2001 13:19:02 -0500 (EST)
From: "David W. Morris" <dwm@xpasc.com>
X-Sender:  <dwm@ncal.verio.com>
To: Erik Aronesty <erik@primedata.org>
cc: Tom McLaren <tom@mclaren.tc>, http-wg@cuckoo.hpl.hp.com
MMDF-Warning:  Parse error in original version of preceding line at poindexter-relay.ics.uci.edu
Subject: Re: Logout
In-Reply-To: <1d0f01c075a4$e0c6b8a0$cd4751d1@primedata.org>
Message-ID: <Pine.GSO.4.30.0101031310230.6544-100000@ncal.verio.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"pXrKc.0.yB2.GrsKw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1008
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


On Wed, 3 Jan 2001, Erik Aronesty wrote:

> The site cannot easily know whether or not the request was coming from the
> cache or the client... unless the cache tells it.
>
> Thus the server always relys on a "third party" (the browser or the
> cache)... to manage or respect authentication "state".
>
> It's just an oversight that cookies are "expirable" (they have timeouts and
> they can be forced by the server to expire) and usernames/passwords aren't.
>
> In a way, "cookies" are "more secure" than the security mechanisms built
> into http.

Except that as V1 cookies are implemented, once you set an expiration,
even short on a cookie, it is written to the user's hard drive.  An
immediate exposure which to me negates any value in a timeout.

What makes cookies more secure is that they can be used via a random
opaque token as the value to create a server side notion of a session
which can have expirations, sliding timeouts, re-authentication, etc. And
if an application logout button is clicked, the cookie can be totally
reset by client side javascript OR a serverside update.

I've led a number of teams building web based applications and have never
found http level authentication worth using. The user experience is
confusing at best, the server side authentication processing excessively
complex, error handling impossible to control, etc. It takes writing your
own web server or complex ISAPI/NSAPI exits to control the interaction
with application authentication mechanisms.

So again cookies win.

Dave Morris


From erik@primedata.org Wed Jan  3 18:25:50 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa28280 for <hyper>;
          3 Jan 2001 18:25 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa24440
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 3 Jan 2001 18:25 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id CAA24283;
	Thu, 4 Jan 2001 02:24:01 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id CAA23803;
	Thu, 4 Jan 2001 02:24:00 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id CAA10366; Thu, 4 Jan 2001 02:23:48 GMT
Resent-Date: Thu, 4 Jan 2001 02:23:48 GMT
Message-ID: <1df901c075f5$703a9a60$cd4751d1@primedata.org>
From: Erik Aronesty <erik@primedata.org>
To: "David W. Morris" <dwm@xpasc.com>
Cc: Tom McLaren <tom@mclaren.tc>, http-wg@cuckoo.hpl.hp.com
MMDF-Warning:  Parse error in original version of preceding line at poindexter-relay.ics.uci.edu
References: <Pine.GSO.4.30.0101031310230.6544-100000@ncal.verio.com>
Subject: Re: Logout
Date: Wed, 3 Jan 2001 21:23:15 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
Disposition-Notification-To: "Erik Aronesty" <erik@primedata.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-MDRemoteIP: 209.81.71.205
X-Return-Path: erik@primedata.org
X-MDaemon-Deliver-To: http-wg@cuckoo.hpl.hp.com
Resent-Message-ID: <"yVZeV.0.GW2.SszKw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1009
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


So, "cookies win" because :

    - iis and netscape's support for http authentication are generally lousy

    - http-authentication standard has somehow "slipped" and has been
overlooked in each successive version

    - the "cookie standard" has progressed quickly and supports all of the
things that regular authentication should have supported a long time ago:

        - passing a "server key" to be added to the digest, which can then
be expired on the server
        - setting expiration times

                                            - Erik







----- Original Message -----
From: "David W. Morris" <dwm@xpasc.com>
To: "Erik Aronesty" <erik@primedata.org>
Cc: "Tom McLaren" <tom@mclaren.tc>; <http-wg@cuckoo.hpl.hp.com>
Sent: Wednesday, January 03, 2001 1:19 PM
Subject: Re: Logout


>
> On Wed, 3 Jan 2001, Erik Aronesty wrote:
>
> > The site cannot easily know whether or not the request was coming from
the
> > cache or the client... unless the cache tells it.
> >
> > Thus the server always relys on a "third party" (the browser or the
> > cache)... to manage or respect authentication "state".
> >
> > It's just an oversight that cookies are "expirable" (they have timeouts
and
> > they can be forced by the server to expire) and usernames/passwords
aren't.
> >
> > In a way, "cookies" are "more secure" than the security mechanisms built
> > into http.
>
> Except that as V1 cookies are implemented, once you set an expiration,
> even short on a cookie, it is written to the user's hard drive.  An
> immediate exposure which to me negates any value in a timeout.
>
> What makes cookies more secure is that they can be used via a random
> opaque token as the value to create a server side notion of a session
> which can have expirations, sliding timeouts, re-authentication, etc. And
> if an application logout button is clicked, the cookie can be totally
> reset by client side javascript OR a serverside update.
>
> I've led a number of teams building web based applications and have never
> found http level authentication worth using. The user experience is
> confusing at best, the server side authentication processing excessively
> complex, error handling impossible to control, etc. It takes writing your
> own web server or complex ISAPI/NSAPI exits to control the interaction
> with application authentication mechanisms.
>
> So again cookies win.
>
> Dave Morris
>
>
>



From joris.dobbelsteen@mail.com Sat Jan  6 14:12:56 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa11026 for <hyper>;
          6 Jan 2001 14:12 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa18767
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 6 Jan 2001 14:12 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id WAA25497;
	Sat, 6 Jan 2001 22:10:12 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id WAA28961;
	Sat, 6 Jan 2001 22:10:12 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id WAA16842; Sat, 6 Jan 2001 22:09:44 GMT
Resent-Date: Sat, 6 Jan 2001 22:09:44 GMT
From: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
To: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: RE: Logout
Date: Sat, 6 Jan 2001 23:00:11 +0100
MIME-Version: 1.0
Message-ID: <004f01c0782c$24a06740$01ff1fac@Joris2K.local>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <198b01c07501$13fa9420$cd4751d1@primedata.org>
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	boundary="----=_NextPart_000_0014_01C07834.6A5DD260";
	micalg=SHA1
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Resent-Message-ID: <"R-fq_.0.u44.8OvLw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1010
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

This is a multi-part message in MIME format.

------=_NextPart_000_0014_01C07834.6A5DD260
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

>-----Original Message-----
>From: Erik Aronesty [mailto:erik@primedata.org]
>Sent: Tuesday 02 January, 2001 22:15
>To: Erik Aronesty; Scott Lawrence
>Cc: http-wg@cuckoo.hpl.hp.com; support@microsoft.com
>Subject: Re: Logout
>
>
>
>Sorry I found it... there is a recommendation,
>
>    Microsoft and Netscape just blindly ignore it:
>
>Section 15.6 "Authentication Credentials and Idle Clients":
>
> "In particular, user agents which cache credentials are
>   encouraged to provide a readily accessible mechanism for discarding
>   cached credentials under user control."
>
>Which neither do - even though it's a security hole.
>
IE5+ does have (somewhat hidden) a function to remove the passwords
remembered with the AutoComplete function
(at least on Win2000). You can find it in:  Internet Options -> Content
(Tab) -> Autocomplete (Button) -> Clear Passwords (Button).

Used for forms only. This function also asks you whether you want to store
(instead of cached, it is stored until explicitly removed) the password.


Other passwords you enter for use with HTTP authentication are stored in
the Windows PassWordList. Under Windows 95/98 and probably ME you can read
it with just a simple tool (e.g. PWLTool, Back Orifice, ...). Windows
NT/2000 provide better security on this one, since the tools don't work
here.
On the Windows 95/98 CD (called PWL-something) you can remove the
passwords under Win95/98/ME, but you don't have it available on a public
computer.
Let's not forget, on Windows 95/98/ME security is virtually inexistent.

But here is always asked whether to store the password (or not).


I don't use Netscape......


As for Lynx, this browser seems to 'forget' the passwords ONLY when it is
closed. I didn't test it long enough to check for a timeout, nor did I
read the source of it to see it.



>
>   *** SNIP ***
>

AS for a NEWER mail:

>-----Original Message-----
>From: Erik Aronesty [mailto:erik@primedata.org]
>Sent: Thursday 04 January, 2001 3:23
>To: David W. Morris
>Cc: Tom McLaren; http-wg@cuckoo.hpl.hp.com
>Subject: Re: Logout
>
>
>
>So, "cookies win" because :
>
>    - iis and netscape's support for http authentication are
>generally lousy

Agreed, HTTP authentication is, even as standard FTP authentication (as
the only supported by IIS), also insecure. Only Digest authentication is a
little bit secure by securely hashing the password.
However the servers also have lousy authentication features, it is
possible with IIS to do a little thing with it. I expect it is possible
with IIS to use the internal security in combination with the web
application. You can ask the username, as long as IIS handles the
authentication, but not in every environment.
Also I don't know if it is possible with ISAPI to 'capture' the password,
before it is processed by the IIS server itself.
But still IIS lacks some of the simpler HTTP rules, as IE does for
authentication. IIS responds to e.g. HTTP/2.0 requests, as it shouldn't do
that.
>
>    - http-authentication standard has somehow "slipped" and has been
>overlooked in each successive version
>
Probably HTTP was never designed with reasonable security in mind, jet
other extensions that where needed at that point in time (don't forget
HTTP/1.1 is a standard for 4 years, and designed/developed more than 4
years ago). The authentication protocols that are documented in RFC2617
can be considered insecure (even Digest Authentication has some
weaknesses, not to talk about Basic authentication which has no security
at all).
Also HTTP authentication (methods) do(es)n't depend on sessions, as with
cookies it is possible.

In the past HTTP was used for the www.company.com pages, and such, that
don't require much security. For traffic that needs to be secure, HTTPS
was designed. But encrypting over 100 MB/s or even Gigabytes/s, with
sufficient secure standards, is a hard job for CPUs, if it needs to be
done beside the job of being a (high-volume) HTTP server. Dedicated
hardware (or plenty of processing power by the CPUs) is desired here.

>    - the "cookie standard" has progressed quickly and
>supports all of the
>things that regular authentication should have supported a
>long time ago:
>
>        - passing a "server key" to be added to the digest,
>which can then
>be expired on the server
>        - setting expiration times

An issue with IE is the fact that passwords with forms are still stored.
An issue with all browsers that support cookies, it that they store the
cookie on the system. Here is required that the user activates the logout
function to erase the cookie, or at least make it useless. If the user
refuses this, the next user (or an adversary) can use the functionality
provided on victim's behalf.

Next, what if an adversary finds a way to use his cookie (obtaining it
using spoofing or a man-in-the-middle attack (proxies are suitable for
this)), the adversary can use that cookie on the victim's behalf. However
this is also true for Basic and (maybe for a limited time, due to
'key'-rotation) Digest authentication.
With scripting, it is possible to counter this treat, but not with cookies
alone, as far as I know.


If you want security for HTTP, you should use Secure-HTTP only.
And I see many companies using HTTPS in combination with cookies (e.g.
Microsoft or hotmail(?)).
They switch to HTTPS for authentication and use HTTP when you are logged
in. Doesn't give the full satisfaction of security, but consider the
increased costs that have to be made when you use HTTPS only, in contrast
to HTTP only (see above why).

The next version of HTTP should have better security functions than
currently provides. The current standard doesn't satisfy the requirements
of many servers, today.



- Joris






Note: There once was someone who wrote a draft about ticket-based
authentication about 5 months ago (8-2000). I didn't hear about the draft
any more, so it might as be well vanished. The mail was called
"Ticket-based authentication", that had 2 replies to the HTTP WG. This one
might incorporate what we were looking/asking for...




------=_NextPart_000_0014_01C07834.6A5DD260
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFvzCCAo4w
ggH3oAMCAQICAwPMRjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAwMTIxNDE0MjQxN1oXDTAxMTIxNDE0MjQxN1owTDEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEpMCcGCSqGSIb3DQEJARYaam9yaXMuZG9iYmVsc3RlZW5AbWFpbC5j
b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPpPaMS0YzMXlTJrdpGgxLk0gNE4sgRsYCox
gkpVo6QYVvjDIVWxT7yQv7IgdUKQbXrr7zKBO3+1xoxlmRnIV+6sUd//1b5RSRo8crv6DtfyucB8
WAiQZ4YY4c1sgCGrmWraUk3lWho9vfidkeXJY5cD5tearj9895Aq0PjKkGbPAgMBAAGjNzA1MCUG
A1UdEQQeMByBGmpvcmlzLmRvYmJlbHN0ZWVuQG1haWwuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZI
hvcNAQEEBQADgYEANbAztZ99D8bAIZB5sGAUX5YuXdhQrs1Iq14gNG0VHcfxO5Xu+FtQ5mZq3pp8
34nIYvR74E2v4fTRnomyImxBUZdr/srONKU//zTkVwlht95xB+957BjxK86ulXx/OiTgbgPnP7+T
ii2il8W1KPhmYI6NDqMsko97zJwGs1DoyFgwggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUA
MIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv
d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNl
cnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp
BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAw
WhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES
MBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl
IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz6
3K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzp
q+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAg
pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNV
HQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQf
uIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX
7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKqMIICpgIBATCBmjCB
kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD
Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMDzEYwCQYFKw4DAhoFAKCCAWUwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTA2MjIwMDA4WjAjBgkq
hkiG9w0BCQQxFgQUQktqcfqq+Ujq9SJw4Xqfaj7fs9owWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYI
KoZIhvcNAgUwgasGCSsGAQQBgjcQBDGBnTCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwAgMDzEYwDQYJKoZIhvcNAQEBBQAEgYD4ZftbtSvZ0joGQKfzfoWD9ydKwR8PeqYNpBEB
E6pf1tGhQPSJ52o6XzZfVFWlCrkFn0qtPr0r0zFtIcKGma0YQ4TI7WvKuIPJmkYE/6IU3+wJnwn/
+Z/qzDw+ZhcP6HvtGLPXteEDHmBJ7x+3/rdxejQOf56ddIkbXXVjltEtSwAAAAAAAA==

------=_NextPart_000_0014_01C07834.6A5DD260--


From peterw@usa.net Sat Jan  6 14:35:41 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa11774 for <hyper>;
          6 Jan 2001 14:35 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa24724
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 6 Jan 2001 14:35 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id WAA25899;
	Sat, 6 Jan 2001 22:34:38 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id WAA29380;
	Sat, 6 Jan 2001 22:34:35 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id WAA16964; Sat, 6 Jan 2001 22:34:34 GMT
Resent-Date: Sat, 6 Jan 2001 22:34:34 GMT
Date: Sat, 6 Jan 2001 17:32:50 -0500 (EST)
From: Peter W <peterw@usa.net>
X-Sender:  <peterw@peterw>
To: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: RE: Logout
In-Reply-To: <004f01c0782c$24a06740$01ff1fac@Joris2K.local>
Message-ID: <Pine.LNX.4.30.0101061719110.30194-100000@peterw>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"-MsOS1.0.L84.QrvLw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1011
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


> >    - the "cookie standard" has progressed quickly and
> >supports all of the
> >things that regular authentication should have supported a
> >long time ago:
> >
> >        - passing a "server key" to be added to the digest,
> >which can then
> >be expired on the server
> >        - setting expiration times
>
> An issue with IE is the fact that passwords with forms are still stored.

Can be overcome/forbidden with HTML code.

The big problem with http + Basic auth is the static authentication
information is sent cleartext. Easy replay. I've outlined a
application-based solution in Bugtraq. Basically:

- login to https://server/login/path
- get at least two cookies:
  insecure "ticket" contains server-generated unique value that
    can be used to lookup user info when requesting protected pages
  secure ticket "check", only to login server, only to login path
  [if you serve https content, an "httpsticket" as well]
- central repository matches "ticket" to user, various stateful info
- at logout, the server marks the ticket as invalid; no replay
- periodically, content server can redirect user back to
  https://server/login/path/verify?sendbackto=http://content/foo.html
  - /login/path/verify checks for presence of both "ticket" and "check";
    a net-sniffing bandit will lack "check"; at that point the "ticket"
    is marked in the repository as 'tainted'; when the good user requests
    another document, that user is warned about the taint, required to
    log in again

The login system can be any system you prefer. user/pass, hardware token,
client certificate, whatever. The key is
 - attackers can't see the authentication data
 - they can't replay the insecure cookie, not for long, anyway

> Next, what if an adversary finds a way to use his cookie (obtaining it
> using spoofing or a man-in-the-middle attack (proxies are suitable for
> this)), the adversary can use that cookie on the victim's behalf.

See above.

As for webmail, I've also suggested ways to protect authentication tickets
from hostile email scripting by using one-time tickets for documents
containing untrusted code, e.g. mail reading frames.

> The next version of HTTP should have better security functions than
> currently provides. The current standard doesn't satisfy the requirements
> of many servers, today.

This is the place to make suggestions...

...IMO, with a little creativity the current infrastructure suffices; or,
at least it can't be significantly improved upon.

-Peter


From joris.dobbelsteen@mail.com Mon Jan  8 07:01:47 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa29090 for <hyper>;
          8 Jan 2001 07:01 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa29770
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 8 Jan 2001 07:01 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id OAA06212;
	Mon, 8 Jan 2001 14:59:33 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id OAA20504;
	Mon, 8 Jan 2001 14:59:32 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id OAA09518; Mon, 8 Jan 2001 14:59:13 GMT
Resent-Date: Mon, 8 Jan 2001 14:59:13 GMT
From: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
To: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: RE: Logout
Date: Mon, 8 Jan 2001 15:49:48 +0100
MIME-Version: 1.0
Message-ID: <000601c07982$52d89950$01ff1fac@Joris2K.local>
Content-Type: multipart/signed;
	micalg=SHA1;
	boundary="----=_NextPart_000_0029_01C0798A.9FC46570";
	protocol="application/x-pkcs7-signature"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <Pine.LNX.4.30.0101061719110.30194-100000@peterw>
Resent-Message-ID: <"K7Yvz.0.xI2.EGTMw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1012
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

This is a multi-part message in MIME format.

------=_NextPart_000_0029_01C0798A.9FC46570
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

>-----Original Message-----
>From: Peter W [mailto:peterw@usa.net]
>Sent: Saturday, 6 January 2001 23:33
>To: Joris Dobbelsteen
>Cc: WWW WG (E-mail)
>Subject: RE: Logout
>
>
>> >    - the "cookie standard" has progressed quickly and
>> >supports all of the
>> >things that regular authentication should have supported a
>> >long time ago:
>> >
>> >        - passing a "server key" to be added to the digest,
>> >which can then
>> >be expired on the server
>> >        - setting expiration times
>>
>> An issue with IE is the fact that passwords with forms are 
>still stored.
>
>Can be overcome/forbidden with HTML code.
>
>The big problem with http + Basic auth is the static authentication
>information is sent cleartext. Easy replay. I've outlined a
>application-based solution in Bugtraq. Basically:
>
Basic is completely insecure. Digest has some security hazards:
Server sends a 'key' to use with hashing. When the same 'key' is used,
the hashed password captured can be reused.
Also doesn't digest authentication (nor basic authentication) provide
data integrity.

>- login to https://server/login/path
>- get at least two cookies:
>  insecure "ticket" contains server-generated unique value that
>    can be used to lookup user info when requesting protected pages
>  secure ticket "check", only to login server, only to login path
>  [if you serve https content, an "httpsticket" as well]
>- central repository matches "ticket" to user, various stateful info
>- at logout, the server marks the ticket as invalid; no replay
>- periodically, content server can redirect user back to
>  https://server/login/path/verify?sendbackto=http://content/foo.html
>  - /login/path/verify checks for presence of both "ticket" 
>and "check";
>    a net-sniffing bandit will lack "check"; at that point the "ticket"
>    is marked in the repository as 'tainted'; when the good 
>user requests
>    another document, that user is warned about the taint, required to
>    log in again
>
You get one 'public' ticket for use over HTTP, and one 'secret' that is
used only over the HTTPS for validation of the originator of the
request. That is what I understand....
HTTPS can be used to rotate 'public' ticket (not really public, but
anyone can read it anyway once transmitted over HTTP).

Seems securely enough to me for general purposes, however there are
still some real vulnerabilities...
The 'public' ticket CAN be used, in some occasions, for a (limited)
time.

Next there is no garantee of data integrity. This part I'm missing. I
can hijack a connection and alter it's (unsecured) data, thus sending
damaging messages on your behalf (or someone else).

As for webmail, when this security is implemented on this pad, later on
I can still alter the data, when send over the SMTP 'network'. So in
this case, it's not a real requirement, but when data is send using
SMTP, probably too many messages are send for the adversery to care
about them all.

I would prefer a scenario of an employee downloading and uploading data
from his company, that doesn't require data confidence (there's no data
confidence when using HTTP).

>The login system can be any system you prefer. user/pass, 
>hardware token,
>client certificate, whatever. The key is
> - attackers can't see the authentication data
> - they can't replay the insecure cookie, not for long, anyway
>
>> Next, what if an adversary finds a way to use his cookie 
>(obtaining it
>> using spoofing or a man-in-the-middle attack (proxies are 
>suitable for
>> this)), the adversary can use that cookie on the victim's behalf.
>
>See above.

Think I got it. But still vulnerable, see above...
>
>As for webmail, I've also suggested ways to protect 
>authentication tickets
>from hostile email scripting by using one-time tickets for documents
>containing untrusted code, e.g. mail reading frames.
>
>> The next version of HTTP should have better security functions than
>> currently provides. The current standard doesn't satisfy the 
>requirements
>> of many servers, today.
>
>This is the place to make suggestions...
>
>...IMO, with a little creativity the current infrastructure 
>suffices; or,
>at least it can't be significantly improved upon.
>
>-Peter
>
>

The obvious thing that is still bad is:
* lack of data integrity validation
* possibility to use a 'ticket' for a (limited) time

The all-in-one solution for this problem is this (maybe can be proposed
as a security extension to HTTP):
[Have a good time reading - 20 kB mail message]


===
Hope I didn't make too much typo errors. and the goal/purpose is
clear...
If you find the word "of" and you think it should not appear here, try
whether "or" fits better. The Dutch "of" is the English "or". I tend to
mix these up sometimes (why I don't know).
===


It relies fully on public-key encryption and looks simuliar to S/MIME.
Note that also proxies should be aware of the use of this feature. Maybe
they can be told using cache-control directive not to manipulate the
message?
I suppose "Cache-control: no-transform" can do the job, but fearing many
proxies will not obey to the directive.

In the case that data confidence is required, using HTTPS is required.

*** REQUIREMENTS
SERVER
* Valid certificate to ensure data integrity and orgin authentication.
* Optional: Hardware hashing and hash signing support, to improve
performance dramatically.
CLIENT
/ None
PROXY/GATEWAY
/ None


*** PART ONE: LOGON
The client should generate a key-pair: private key with according public
key. Next the client should be aware of the user's authentication
credentials (user/pass), and should not save these (without explicitly
asking the user). A HTTP connection can be used to ask the sever for a
SessionID, and at the same time send the user's authentication
credentials and the public key. The client can purpose a lifetime of the
session and for the key. Also the algorithms used must be agreed on by
the client and server. In case of unsecured transmission (HTTP, not for
HTTPS), the HTTP message should be signed.
In case of the correct credentials are used, and the server agrees on
the methods/protocols used, the server sends his certificate (with
public key) and a session ID.

In reality this can be done over HTTPS, using Digest authentication by
preference.
The client connects to a HTTP server using HTTPS. Next it sends it's
authentication credentials, with the password hashed (standard digest
authentication), but also includes the public key. No need to sign the
message (already secure channel).
Assuming the correct ID and server accepts methods used...
The server responds with a a SessionID, and a certificate. Also the
server specifies where the SessionID should/can be used and gives
servernames with the according certificates, or a group that uses the
same certificate. Also expiration of the sessionID and maybe the key is
included (when using 1024-bit or larger keys, this is not required).
Messsage doesn't need be signed, because the connection is secure.


If the user has a certificate already, this can be used, instead of the
custom-generated key-pair. The entire certificate should be send in this
case, instead of only the public key.
With the appropiate methods, HTTPS will not be needed. This sample used
the old authentication methods in combination with the new features
provided by this security extension.

It is possible to use certificate authentication together with the
user/password authentication, but allowing a higher level of access when
using certificate authentication.

The server must send the certificate to identify itself, as it has no
user/password authentication possibility, but the certificate alone will
be enough for the job.

Note that the rule (for certificates) is that the private key NEVER
leaves the local computer, but only the public key. When I say, send the
certificate, only the certificate with the public key and withOUT the
private key. This applies through all this specification. No confusion
on this...


*** PART TWO: HTTP MESSAGE SIGNING

On unsecure channels, we sign the HTTP message.
We need to sign data that is affected, this includes the Request/Reponse
line and non-modifiable headers. The headers that can be signed are
outlined in section 13.5.2 (Non-modifiable Headers). Also the header
including the sessionID should be signed.

We need a hash of the request/response line, headers and, of course, the
content (data). Next the hash should be signed with the private key. The
public key cannot be used for signing, because the adversery also knows
the public key.

This means the remote side can check the data intigrity. The SessionID
will be used to check the user credentials.


*** PART THREE: LOGOFF
Logoff occurs quire simply by expiration of the SessionID or sending an
instruction to the server to logoff. The server can also instruct the
client to logoff.
Logoff includes the expiration of the SessionID and erasing the key-pair
on the client. Most important is the expiration of the SessionID to
succeed on the server-side.
This means LOGOFF IS REQUIRED using either expiration or user-actived
logoff!!!


*** PART FOUR: EXTENDING SESSION LIFETIME
Resons for ending a session without intension of the user is expiration
of the SessionID. Before extending the session, the user should be aware
of it, by asking him/her/it first. Closing the browser should retire the
SessionID and key-pairs and preferably, the server should send a message
to retire the session.

A signed message with this request can be issued to the (original)
authentication server in order to extend the session for a specific time
(maximum limit by the server). The server may refuse. Adding user
credentials again is not needed but may be requested by the server. Also
key rotation or sessionID rotation may be requested/done by the server.


*** PART FIVE: WEAKNESSES/DISADVANTAGES OF THE PROTOCOL
The protocol requires on the strength of the security protocols used.
Known-plaintext attacks are possible, and security protocols used should
be designed to be properly (heavily) protected against this type of
attack. Such attacks can result fast into many known-plaintexts with
there accompanying ciphertext.

Servers require significanly more performance to do the job.

Key- and session-management is required and probably will get more
complex.

Requires browser and server support.

Expire-times should be relatively short (couple minutes), to improve
security. Long expire-times give the adversery a good chance to do
damage. This is because delivery is still not ensured, and thus
retirement of sessions by the user is not garanteed to happen (you can
easily filter such messages out).


*** PART SIX: FEATURES OF THE PROTOCOL
Provides orgin authentication

Provides data integrity

Extended security over existing methods, by eliminating some severe
weaknesses that exist in the cookies-implementation.

Long sessionkeys (256-bits would probably allow you to have almost
certainly unique IDs)

A (e.g. authentication) server can have a different certificate that the
other servers.


*** PART SEVEN: WORK TO DO
- How on chunked transfers
- How to sign headers and the request/response line.
  These probably change due to proxies, gateways, firewalls and such
things.
- .....



That was the mail for today...
Hope you like it.

If you have some other suggestions, send them...
maybe some protocol errors, but it probably needs to be reviewed, when
we want to implement such functionality.
Maybe I forget thinks where, I did or didn't think about...



- Joris

------=_NextPart_000_0029_01C0798A.9FC46570
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFvzCCAo4w
ggH3oAMCAQICAwPMRjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAwMTIxNDE0MjQxN1oXDTAxMTIxNDE0MjQxN1owTDEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEpMCcGCSqGSIb3DQEJARYaam9yaXMuZG9iYmVsc3RlZW5AbWFpbC5j
b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPpPaMS0YzMXlTJrdpGgxLk0gNE4sgRsYCox
gkpVo6QYVvjDIVWxT7yQv7IgdUKQbXrr7zKBO3+1xoxlmRnIV+6sUd//1b5RSRo8crv6DtfyucB8
WAiQZ4YY4c1sgCGrmWraUk3lWho9vfidkeXJY5cD5tearj9895Aq0PjKkGbPAgMBAAGjNzA1MCUG
A1UdEQQeMByBGmpvcmlzLmRvYmJlbHN0ZWVuQG1haWwuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZI
hvcNAQEEBQADgYEANbAztZ99D8bAIZB5sGAUX5YuXdhQrs1Iq14gNG0VHcfxO5Xu+FtQ5mZq3pp8
34nIYvR74E2v4fTRnomyImxBUZdr/srONKU//zTkVwlht95xB+957BjxK86ulXx/OiTgbgPnP7+T
ii2il8W1KPhmYI6NDqMsko97zJwGs1DoyFgwggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUA
MIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv
d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNl
cnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp
BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAw
WhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES
MBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl
IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz6
3K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzp
q+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAg
pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNV
HQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQf
uIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX
7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKqMIICpgIBATCBmjCB
kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD
Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMDzEYwCQYFKw4DAhoFAKCCAWUwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTA4MTQ0OTQ1WjAjBgkq
hkiG9w0BCQQxFgQU7wSHGsw8Linytz3MnoHumUfMi7kwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYI
KoZIhvcNAgUwgasGCSsGAQQBgjcQBDGBnTCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwAgMDzEYwDQYJKoZIhvcNAQEBBQAEgYDX/nFsIzf0tnMPNpkvVGXVExiejwZUgLXA/5j9
nC4OG666uciCBtKt2YuH9UxPm5MSoqrR3P7SviNGGmWwIrehJzT9nGRubXfaLRN4xzMGucfT2XzO
JR18ZlYz+MM8xtc9ko9QQCC2TACiC4koKjmDB3gROox/Hc0KFFQ2LMjbYQAAAAAAAA==

------=_NextPart_000_0029_01C0798A.9FC46570--


From joris.dobbelsteen@mail.com Mon Jan  8 10:05:00 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa11419 for <hyper>;
          8 Jan 2001 10:04 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa05391
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 8 Jan 2001 10:03 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id SAA13395;
	Mon, 8 Jan 2001 18:02:21 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA28600;
	Mon, 8 Jan 2001 18:02:20 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id SAA10386; Mon, 8 Jan 2001 18:02:09 GMT
Resent-Date: Mon, 8 Jan 2001 18:02:09 GMT
From: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
To: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: RE: Logout
Date: Mon, 8 Jan 2001 18:57:43 +0100
MIME-Version: 1.0
Message-ID: <000001c0799c$80a8a950$01ff1fac@Joris2K.local>
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	boundary="----=_NextPart_000_0010_01C079A4.E0287880";
	micalg=SHA1
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <Pine.LNX.4.30.0101061719110.30194-100000@peterw>
Resent-Message-ID: <"Y481c3.0.kW2.80WMw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1013
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C079A4.E0287880
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

A stupid mistake made in the previous mail...

Hashing and signing the hash is always required, because it is an
intergral part of the orgin authentication (and data integrity)
validation. Corrected in this mail (I really hope)...

==============================

The obvious thing that is still bad is:
* lack of data integrity validation
* possibility to use a 'ticket' for a (limited) time

The all-in-one solution for this problem is this (maybe can be proposed
as a security extension to HTTP):
[Have a good time reading - 20 kB mail message]


===
Hope I didn't make too much typo errors. and the goal/purpose is
clear...
If you find the word "of" and you think it should not appear here, try
whether "or" fits better. The Dutch "of" is the English "or". I tend to
mix these up sometimes (why I don't know).
===


It relies fully on public-key encryption and looks simuliar to S/MIME.
Note that also proxies should be aware of the use of this feature. Maybe
they can be told using cache-control directive not to manipulate the
message?
I suppose "Cache-control: no-transform" can do the job, but fearing many
proxies will not obey to the directive.

In the case that data confidence is required, using HTTPS is required.

*** REQUIREMENTS
SERVER
* Valid certificate to ensure data integrity and orgin authentication.
* Optional: Hardware hashing and hash signing support, to improve
performance dramatically.
CLIENT
/ None
PROXY/GATEWAY
/ None


*** PART ONE: LOGON
The client should generate a key-pair: private key with according public
key. Next the client should be aware of the user's authentication
credentials (user/pass), and should not save these (without explicitly
asking the user). A HTTP connection can be used to ask the sever for a
SessionID, and at the same time send the user's authentication
credentials and the public key. The client can purpose a lifetime of the
session and for the key. Also the algorithms used must be agreed on by
the client and server. Next the message must be signed, as it provides a
integral part of the orgin authentication and data integrity check.
On a secure channel, in a logon message ONLY, it's not a direct
requirement that the message is signed

In case of the correct credentials are used, and the server agrees on
the methods/protocols used, the server sends his certificate (with
public key) and a session ID.

In reality this can be done over HTTPS, using Digest authentication by
preference.
The client connects to a HTTPS server. Next it sends it's authentication
credentials, with the password hashed (standard digest authentication),
but also includes the public key. No need to sign the message (already
secure channel, note that this is for a logon message only).
Assuming the correct ID and server accepts methods used...
The server responds with a a SessionID, and a certificate. Also the
server specifies where the SessionID should/can be used and gives
servernames with the according certificates, or a group that uses the
same certificate. Also expiration of the sessionID and maybe the key is
included (when using 1024-bit or larger keys, this is not required).
Messsage doesn't need be signed, because the connection is secure.


If the user has a certificate already, this can be used, instead of the
custom-generated key-pair. The entire certificate should be send in this
case, instead of only the public key.
With the appropiate methods, HTTPS will not be needed. This sample used
the old authentication methods in combination with the new features
provided by this security extension.

It is possible to use certificate authentication together with the
user/password authentication, but allowing a higher level of access when
using certificate authentication.

The server must send the certificate to identify itself, as it has no
user/password authentication possibility, but the certificate alone will
be enough for the job.

Note that the rule (for certificates) is that the private key NEVER
leaves the local computer, but only the public key. When I say, send the
certificate, only the certificate with the public key and withOUT the
private key. This applies through all this specification. No confusion
on this...


*** PART TWO: HTTP MESSAGE SIGNING

On unsecure and SECURE channels, we sign the HTTP(S) message.
We need to sign data that can be affected by an adversery in a way that
it will provide a security hole, this includes the Request/Reponse line
and non-modifiable headers. The headers that can be signed are outlined
in section 13.5.2 (Non-modifiable Headers). Also the header including
the sessionID should be signed.

We need a hash of the request/response line, headers and, of course, the
content (data). Next the hash should be signed with the private key. The
public key cannot be used for signing, because the adversery also knows
the public key.

This means the remote side can check the data intigrity. The SessionID
will be used to check the user credentials.

Note that signing is an important operation, as it provides orgin
authentication and data integrity.


*** PART THREE: LOGOFF
Logoff occurs quire simply by expiration of the SessionID or sending an
instruction to the server to logoff. The server can also instruct the
client to logoff.
Logoff includes the expiration of the SessionID and erasing the key-pair
on the client. Most important is the expiration of the SessionID to
succeed on the server-side.
This means LOGOFF IS REQUIRED using either expiration or user-actived
logoff!!!
Logoff messages must be signed.


*** PART FOUR: EXTENDING SESSION LIFETIME
Resons for ending a session without intension of the user is expiration
of the SessionID. Before extending the session, the user should be aware
of it, by asking him/her/it first. Closing the browser should retire the
SessionID and key-pairs and preferably, the server should send a message
to retire the session.

A signed message with this request can be issued to the (original)
authentication server in order to extend the session for a specific time
(maximum limit by the server). The server may refuse. Adding user
credentials again is not needed but may be requested by the server. Also
key rotation or sessionID rotation may be requested/done by the server.


*** PART FIVE: WEAKNESSES/DISADVANTAGES OF THE PROTOCOL
The protocol requires on the strength of the security protocols used.
Known-plaintext attacks are possible, and security protocols used should
be designed to be properly (heavily) protected against this type of
attack. Such attacks can result fast into many known-plaintexts with
there accompanying ciphertext.

Servers require significanly more performance to do the job.

Key- and session-management is required and probably will get more
complex.

Requires browser and server support.

Expire-times should be relatively short (couple minutes), to improve
security. Long expire-times give the adversery a good chance to do
damage. This is because delivery is still not ensured, and thus
retirement of sessions by the user is not garanteed to happen (you can
easily filter such messages out).


*** PART SIX: FEATURES OF THE PROTOCOL
Provides orgin authentication

Provides data integrity

Extended security over existing methods, by eliminating some severe
weaknesses that exist in the cookies-implementation.

Long sessionkeys (256-bits would probably allow you to have almost
certainly unique IDs)

A (e.g. authentication) server can have a different certificate that the
other servers.


*** PART SEVEN: WORK TO DO
- How on chunked transfers
- How to sign headers and the request/response line.
  These probably change due to proxies, gateways, firewalls and such
things.
- .....


*** PART EIGTH: HACKING ATTEMPTS
If a false message was detected that was incorrectly signed, the server
should notify the actual owner of the session of this attempt. It's
recommended to retire the session. On the other hand, the session can
probably continue to exist, because this security is more difficult to
break, than with the cookies.



That was the mail for today...
Hope you like it.

If you have some other suggestions, send them...
maybe some protocol errors, but it probably needs to be reviewed, when
we want to implement such functionality.
Maybe I forget thinks where, I did or didn't think about...



- Joris

------=_NextPart_000_0010_01C079A4.E0287880
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFvzCCAo4w
ggH3oAMCAQICAwPMRjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAwMTIxNDE0MjQxN1oXDTAxMTIxNDE0MjQxN1owTDEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEpMCcGCSqGSIb3DQEJARYaam9yaXMuZG9iYmVsc3RlZW5AbWFpbC5j
b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPpPaMS0YzMXlTJrdpGgxLk0gNE4sgRsYCox
gkpVo6QYVvjDIVWxT7yQv7IgdUKQbXrr7zKBO3+1xoxlmRnIV+6sUd//1b5RSRo8crv6DtfyucB8
WAiQZ4YY4c1sgCGrmWraUk3lWho9vfidkeXJY5cD5tearj9895Aq0PjKkGbPAgMBAAGjNzA1MCUG
A1UdEQQeMByBGmpvcmlzLmRvYmJlbHN0ZWVuQG1haWwuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZI
hvcNAQEEBQADgYEANbAztZ99D8bAIZB5sGAUX5YuXdhQrs1Iq14gNG0VHcfxO5Xu+FtQ5mZq3pp8
34nIYvR74E2v4fTRnomyImxBUZdr/srONKU//zTkVwlht95xB+957BjxK86ulXx/OiTgbgPnP7+T
ii2il8W1KPhmYI6NDqMsko97zJwGs1DoyFgwggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUA
MIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv
d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNl
cnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp
BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAw
WhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES
MBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl
IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz6
3K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzp
q+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAg
pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNV
HQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQf
uIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX
7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKqMIICpgIBATCBmjCB
kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD
Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMDzEYwCQYFKw4DAhoFAKCCAWUwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTA4MTc1NzQwWjAjBgkq
hkiG9w0BCQQxFgQUH2Nnoe+mWfoU+N+OrBmoijvxJWgwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYI
KoZIhvcNAgUwgasGCSsGAQQBgjcQBDGBnTCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwAgMDzEYwDQYJKoZIhvcNAQEBBQAEgYAySyg/iSxqQ02XHC0xEX8GsorYHAGMWxoNzi8U
hjIlypSyLQJUaWotvThg54k5D1hleVxwU+01sdRHq0HNfiuvFv0XjTTKqGmTYjlx+bg3byRS9mde
59XVJUTs3DnUBWXt/CbeqVOStWgRrdtOdUW/r/thhBC01HbZp/yc9oZZzQAAAAAAAA==

------=_NextPart_000_0010_01C079A4.E0287880--


From joris.dobbelsteen@mail.com Mon Jan  8 10:10:07 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa12081 for <hyper>;
          8 Jan 2001 10:10 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa06360
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 8 Jan 2001 10:09 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id SAA13724;
	Mon, 8 Jan 2001 18:09:11 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA28826;
	Mon, 8 Jan 2001 18:09:08 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id SAA10529; Mon, 8 Jan 2001 18:09:07 GMT
Resent-Date: Mon, 8 Jan 2001 18:09:07 GMT
From: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
To: 'Scott Lawrence' <slawrence@virata.com>
Cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: RE: Logout
Date: Mon, 8 Jan 2001 19:03:32 +0100
MIME-Version: 1.0
Message-ID: <000701c0799d$508b32a0$01ff1fac@Joris2K.local>
X-Priority: 3 (Normal)
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	boundary="----=_NextPart_000_0015_01C079A5.B13F8A30";
	micalg=SHA1
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3A59F9CA.8040103@virata.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Resent-Message-ID: <"30P5l1.0.kZ2.m8WMw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1014
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01C079A5.B13F8A30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

>-----Original Message-----
>From: Scott Lawrence [mailto:slawrence@virata.com]
>Sent: Monday, 8 January 2001 18:33
>To: Joris Dobbelsteen
>Cc: WWW WG (E-mail)
>Subject: Re: Logout
>
>
>Joris Dobbelsteen wrote:
>
>
>> Basic is completely insecure. Digest has some security hazards:
>> Server sends a 'key' to use with hashing. When the same 
>'key' is used,
>> the hashed password captured can be reused.
>> Also doesn't digest authentication (nor basic authentication) provide
>> data integrity.
>
>Actually, the Digest spec provides a content integrity mechanism 
>(qop=auth-int).  It does not protect most of the header information 
>(because of compatibility problems with proxies), but does protect 
>and authenticate the message body by including a hash of the message 
>body as an input to the response hash.
>
Wasn't aware of the hash included of the message body.

>As for alternative schemes that provide better security without 
>SSL/TLS, there was a very good spec "The Secure HyperText Transfer 
>Protocol" that just didn't get any traction with implementors:
>
>http://www.ietf.org/rfc/rfc2660.txt
>
>
I will read RFC2660....


- Joris

------=_NextPart_000_0015_01C079A5.B13F8A30
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFvzCCAo4w
ggH3oAMCAQICAwPMRjANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAwMTIxNDE0MjQxN1oXDTAxMTIxNDE0MjQxN1owTDEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEpMCcGCSqGSIb3DQEJARYaam9yaXMuZG9iYmVsc3RlZW5AbWFpbC5j
b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPpPaMS0YzMXlTJrdpGgxLk0gNE4sgRsYCox
gkpVo6QYVvjDIVWxT7yQv7IgdUKQbXrr7zKBO3+1xoxlmRnIV+6sUd//1b5RSRo8crv6DtfyucB8
WAiQZ4YY4c1sgCGrmWraUk3lWho9vfidkeXJY5cD5tearj9895Aq0PjKkGbPAgMBAAGjNzA1MCUG
A1UdEQQeMByBGmpvcmlzLmRvYmJlbHN0ZWVuQG1haWwuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZI
hvcNAQEEBQADgYEANbAztZ99D8bAIZB5sGAUX5YuXdhQrs1Iq14gNG0VHcfxO5Xu+FtQ5mZq3pp8
34nIYvR74E2v4fTRnomyImxBUZdr/srONKU//zTkVwlht95xB+957BjxK86ulXx/OiTgbgPnP7+T
ii2il8W1KPhmYI6NDqMsko97zJwGs1DoyFgwggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUA
MIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv
d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNl
cnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp
BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAw
WhcNMDIwODI5MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES
MBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl
IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz6
3K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzp
q+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAg
pB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNV
HQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQf
uIdjdBxtt88aU5FL4c3mONntUPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX
7xe21Yibt6KIGu05Wzl9NPy2lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKqMIICpgIBATCBmjCB
kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD
Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMDzEYwCQYFKw4DAhoFAKCCAWUwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTA4MTgwMzMxWjAjBgkq
hkiG9w0BCQQxFgQUc3Kuwcafwol3u7SKA2nJ/6nOYKQwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYI
KoZIhvcNAgUwgasGCSsGAQQBgjcQBDGBnTCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwAgMDzEYwDQYJKoZIhvcNAQEBBQAEgYDJsR2NGsUPLLvPHScpTy30me/Yb6ZrpOTTh35o
JiZcIF/kK5HyKgy/GKJgvOtQbEQaXusMWV3MEgvafxptFJUj0SjCf34oh9Vyx6Sw+sBEE9CMFUL7
q4xF5pdcTx85BQaW1fcm9LAbkivX1yE7+b2ITod0bzvhWT+8SX2UTQ/znwAAAAAAAA==

------=_NextPart_000_0015_01C079A5.B13F8A30--


From Jeff.Hodges@kingsmountain.com Wed Jan 10 14:14:58 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa05001 for <hyper>;
          10 Jan 2001 14:14 PST
Received: from hplb.hpl.hp.com  ( hplb-temp.hpl.hp.com [192.6.10.50] )
          by poindexter-relay.ics.uci.edu id aa08240
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 10 Jan 2001 14:14 PST
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id WAA01460;
	Wed, 10 Jan 2001 22:12:24 GMT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id WAA06923;
	Wed, 10 Jan 2001 22:12:23 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id WAA06233; Wed, 10 Jan 2001 22:11:45 GMT
Resent-Date: Wed, 10 Jan 2001 22:11:45 GMT
Message-Id: <200101102201.OAA02139@breakaway.Stanford.EDU>
X-Mailer: exmh version 2.0.2 2/24/98
Subject: Re: Response to "On the use of HTTP as a Substrate for Other 
 Protocols"
To: ietf@ietf.org
cc: http-wg@cuckoo.hpl.hp.com
Reply-to: ietf@ietf.org
From: Jeff.Hodges@kingsmountain.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 10 Jan 2001 14:01:56 -0800
Sender: hodges@breakaway.stanford.edu
Resent-Message-ID: <"tPO7i.0.HW1.xoDNw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1015
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

See..

  http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0061.html

..for a response (by individuals participating in the W3C XML Protocol work) 
to the IETF-wide Last Call of..

  ftp://ftp.ietf.org/internet-drafts/draft-moore-using-http-01.txt

The response was sent directly to the iesg, as indicated here..

  http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0178.html

I'm forwarding it to this list in case there's innarested folks here that were 
otherwise unaware of it.

JeffH



From Howard@silverstream.com Wed Feb  7 08:52:12 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa25076 ; 7 Feb 2001 08:52 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa18591 ; 7 Feb 2001 08:52 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id QAA04857;
	Wed, 7 Feb 2001 16:51:01 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id QAA22975; Wed, 7 Feb 2001 16:50:44 GMT
Resent-Date: Wed, 7 Feb 2001 16:50:44 GMT
From: "Melman, Howard" <Howard@silverstream.com>
To: HTTP Working Group <http-wg@cuckoo.hpl.hp.com>
X-Mailer: emacs 20.6.1 (via feedmail 8 I);
	VM 6.90 under Emacs 20.6.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14977.31693.34000.813690@gargle.gargle.HOWL>
Date: Wed, 7 Feb 2001 11:46:05 -0500
Subject: can charsets be quoted.
Resent-Message-ID: <"dZSpq1.0.Nc5.enNWw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1016
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


Is this legal:

    Content-Type: text/html; charset="iso-8859-1"

Specifically are the double quotes around the charset value
legal?  I assume the intent is that they are, but I believe
the spec as written doesn't allow for them.  I know others
(like WebDAV) assume you can use double quotes, and I know
it's legal in MIME (see below)

In RFC 2616 14.17 Content-Type refers you to 3.7 on media
types.  3.7 defines media-type as:

       media-type     = type "/" subtype *( ";" parameter )

and refers you to 3.6 to define parameter.  3.6 says:

   Parameters are in  the form of attribute/value pairs.

       parameter               = attribute "=" value
       attribute               = token
       value                   = token | quoted-string

so the values can be a token or a quoted-string, great, it
seems that charset values can be quoted.  BUT the last
paragraph of 3.7.1 says:

   The "charset" parameter is used with some media types to define the
   character set (section 3.4) of the data. When no explicit charset
   parameter is provided by the sender, media subtypes of the "text"
   type are defined to have a default charset value of "ISO-8859-1" when
   received via HTTP. Data in character sets other than "ISO-8859-1" or
   its subsets MUST be labeled with an appropriate charset value. See
   section 3.4.1 for compatibility problems.

Specifically referring us to section 3.4 for the definition
of the charset parameter.  3.4 defines charset as:

   HTTP character sets are identified by case-insensitive tokens. The
   complete set of tokens is defined by the IANA Character Set registry
   [19].

       charset = token

And "token" doesn't allow quotes.  Shouldn't this be:

       charset = token | quoted-string

or else, doesn't the spec disallow quotes around charset
values?  Or should section 3.4 not offer a BNF for charset
at all in which case it would be clear that it's just
another parameter and therefore the value is token or
quoted-string?  Or, at least, section 3.4 should say that
this BNF is semantic and that quotes around token are used
to delimit the parameter (see below).  

If you're trying to figure out what the spec says for
charset values, and you turn to section 3.4 since it defines
charsets, in it's current form, you get a very different
notion of what's allowed then I think is intended.

Howard


MIME's view of things, as best as I can find, is RFC 2045 section 5.1:

   Note that the value of a quoted string parameter does not include the
   quotes.  That is, the quotation marks in a quoted-string are not a
   part of the value of the parameter, but are merely used to delimit
   that parameter value.  In addition, comments are allowed in
   accordance with RFC 822 rules for structured header fields.  Thus the
   following two forms

     Content-type: text/plain; charset=us-ascii (Plain text)

     Content-type: text/plain; charset="us-ascii"

   are completely equivalent.




From joris.dobbelsteen@mail.com Wed Feb  7 13:10:11 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa18109 ; 7 Feb 2001 13:10 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa14836 ; 7 Feb 2001 13:10 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id VAA11374;
	Wed, 7 Feb 2001 21:09:20 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id VAA24171; Wed, 7 Feb 2001 21:09:04 GMT
Resent-Date: Wed, 7 Feb 2001 21:09:04 GMT
From: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
To: "'Melman, Howard'" <Howard@silverstream.com>
Cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: RE: can charsets be quoted.
Date: Wed, 7 Feb 2001 21:59:01 +0100
Message-ID: <000801c09149$7bea59d0$01ff1fac@Joris2K.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <14977.31693.34000.813690@gargle.gargle.HOWL>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Resent-Message-ID: <"XXIKG3.0.ku5.pZRWw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1017
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

Interresting problem

>-----Original Message-----
>From: Melman, Howard [mailto:Howard@silverstream.com]
>Sent: Wednesday, 07 February 2001 17:46
>To: HTTP Working Group
>Subject: can charsets be quoted.
>
>
>
>Is this legal:
>
>    Content-Type: text/html; charset="iso-8859-1"
>
>Specifically are the double quotes around the charset value
>legal?  I assume the intent is that they are, but I believe
>the spec as written doesn't allow for them.  I know others
>(like WebDAV) assume you can use double quotes, and I know
>it's legal in MIME (see below)
>
>In RFC 2616 14.17 Content-Type refers you to 3.7 on media
>types.  3.7 defines media-type as:
>
>       media-type     = type "/" subtype *( ";" parameter )
>
>and refers you to 3.6 to define parameter.  3.6 says:
>
>   Parameters are in  the form of attribute/value pairs.
>
>       parameter               = attribute "=" value
>       attribute               = token
>       value                   = token | quoted-string
>

Till here it seems to be all right....


>so the values can be a token or a quoted-string, great, it
>seems that charset values can be quoted.  BUT the last
>paragraph of 3.7.1 says:
>
>   The "charset" parameter is used with some media types to define the
>   character set (section 3.4) of the data. When no explicit charset
>   parameter is provided by the sender, media subtypes of the "text"
>   type are defined to have a default charset value of
>"ISO-8859-1" when
>   received via HTTP. Data in character sets other than "ISO-8859-1" or
>   its subsets MUST be labeled with an appropriate charset value. See
>   section 3.4.1 for compatibility problems.
>
>Specifically referring us to section 3.4 for the definition
>of the charset parameter.  3.4 defines charset as:
>
>   HTTP character sets are identified by case-insensitive tokens. The
>   complete set of tokens is defined by the IANA Character Set registry
>   [19].
>
>       charset = token
>
>And "token" doesn't allow quotes.  Shouldn't this be:
>
>       charset = token | quoted-string

Well, it doesn't point explicitly to the value, thus:
  value = charset | token | quoted-string

Something like this would then have been in the spec

I expect is to be all right what you do.

>
>or else, doesn't the spec disallow quotes around charset
>values?  Or should section 3.4 not offer a BNF for charset
>at all in which case it would be clear that it's just
>another parameter and therefore the value is token or
>quoted-string?  Or, at least, section 3.4 should say that
>this BNF is semantic and that quotes around token are used
>to delimit the parameter (see below).
>
>If you're trying to figure out what the spec says for
>charset values, and you turn to section 3.4 since it defines
>charsets, in it's current form, you get a very different
>notion of what's allowed then I think is intended.
>
>Howard
>
>
>MIME's view of things, as best as I can find, is RFC 2045 section 5.1:
>
>   Note that the value of a quoted string parameter does not
>include the
>   quotes.  That is, the quotation marks in a quoted-string are not a
>   part of the value of the parameter, but are merely used to delimit
>   that parameter value.  In addition, comments are allowed in
>   accordance with RFC 822 rules for structured header fields.
> Thus the
>   following two forms
>
>     Content-type: text/plain; charset=us-ascii (Plain text)
>
>     Content-type: text/plain; charset="us-ascii"
>
>   are completely equivalent.
>

HTTP has much of it's design from MIME, probably you can use the
quoted-string, and it's compliant withe spec.

However, I don't know if client implementation support it, but I expect they
will, through I'm not sure, nor have any possibility to test this. This is
actually the issue with things like this.

The only server I found: HEAD http://www.freebsd.com/ HTTP/1.1
returned the value of the parameter "charset" without quotes.
I would recommend to simply not use them, just in case...



- Joris


From Howard@silverstream.com Thu Feb  8 10:54:14 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa10498 ; 8 Feb 2001 10:54 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa14292 ; 8 Feb 2001 10:54 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id SAA26311;
	Thu, 8 Feb 2001 18:52:59 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id SAA05626; Thu, 8 Feb 2001 18:52:41 GMT
Resent-Date: Thu, 8 Feb 2001 18:52:41 GMT
From: "Melman, Howard" <Howard@silverstream.com>
To: HTTP WG <http-wg@cuckoo.hpl.hp.com>
Cc: Joris Dobbelsteen <joris.dobbelsteen@mail.com>, 
    Paul Leach <paulle@exchange.microsoft.com>, 
    "Melman, Howard" <Howard@silverstream.com>
X-Mailer: emacs 20.6.1 (via feedmail 8 I);
	VM 6.90 under Emacs 20.6.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14978.59949.384000.21123@gargle.gargle.HOWL>
Date: Thu, 8 Feb 2001 13:49:17 -0500
Subject: RE: can charsets be quoted.
In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657406005947@DF-BOWWOW.platinum.corp.microsoft.com>
References: <5B90AD65A9E8934987DB0C8C0762657406005947@DF-BOWWOW.platinum.corp.microsoft.com>
Resent-Message-ID: <"2_KlG1.0.ZN1.zfkWw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1018
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


On Wednesday Feb 7, 2001, Paul Leach wrote:

> I believe that the word token is being used two different ways.
> This way:
> 	value                   = token | quoted-string
> and in this sentence:
> 	HTTP character sets are identified by case-insensitive tokens.
> 
> The first one is a formal ABNF definition, the second is not. I.e.,
> there was no intent to say that char-set IDs have to be "tokens" as that
> is specified in the HTTP ABNF.
> 
> I would say that it is perfectly legal for them to be quoted.

I agree.  But I think the spec could be clearer in two ways.
I think the ABNF should be removed from 3.4 (since it's not
intended) and I think the word "token" should be replaced
with the word "name" in all cases in section 3.4.  The IANA
does not refer to charset tokens, but rather charset names.
See RFC 1700 or
http://www.isi.edu/in-notes/iana/assignments/character-sets

Howard


From LMM@acm.org Fri Feb  9 10:01:30 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa14212 ; 9 Feb 2001 10:01 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa03646 ; 9 Feb 2001 10:01 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id RAA28434;
	Fri, 9 Feb 2001 17:59:58 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id RAA16793; Fri, 9 Feb 2001 17:59:43 GMT
Resent-Date: Fri, 9 Feb 2001 17:59:43 GMT
From: Larry Masinter <LMM@acm.org>
To: Melman Howard <Howard@silverstream.com>, 
    HTTP WG <http-wg@cuckoo.hpl.hp.com>
Cc: Joris Dobbelsteen <joris.dobbelsteen@mail.com>, 
    Paul Leach <paulle@exchange.microsoft.com>
Subject: RE: can charsets be quoted.
Date: Fri, 9 Feb 2001 09:53:09 -0800
Message-ID: <NDBBKEBDLFENBJCGFOIJMEENEGAA.LMM@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <14978.59949.384000.21123@gargle.gargle.HOWL>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Resent-Message-ID: <"-UyuE3.0.W54.G-2Xw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1019
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

Hopefully this will get on the "errata" page...

> -----Original Message-----
> From: Melman, Howard [mailto:Howard@silverstream.com]
> Sent: Thursday, February 08, 2001 10:49 AM
> To: HTTP WG
> Cc: Joris Dobbelsteen; Paul Leach; Melman, Howard
> Subject: RE: can charsets be quoted.
> 
> 
> 
> On Wednesday Feb 7, 2001, Paul Leach wrote:
> 
> > I believe that the word token is being used two different ways.
> > This way:
> > 	value                   = token | quoted-string
> > and in this sentence:
> > 	HTTP character sets are identified by case-insensitive tokens.
> > 
> > The first one is a formal ABNF definition, the second is not. I.e.,
> > there was no intent to say that char-set IDs have to be "tokens" as that
> > is specified in the HTTP ABNF.
> > 
> > I would say that it is perfectly legal for them to be quoted.
> 
> I agree.  But I think the spec could be clearer in two ways.
> I think the ABNF should be removed from 3.4 (since it's not
> intended) and I think the word "token" should be replaced
> with the word "name" in all cases in section 3.4.  The IANA
> does not refer to charset tokens, but rather charset names.
> See RFC 1700 or
> http://www.isi.edu/in-notes/iana/assignments/character-sets
> 
> Howard
> 


From fielding@ebuilt.com Fri Feb  9 12:12:21 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa26650 ; 9 Feb 2001 12:12 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa12419 ; 9 Feb 2001 12:12 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id UAA01634;
	Fri, 9 Feb 2001 20:10:26 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id UAA17438; Fri, 9 Feb 2001 20:10:08 GMT
Resent-Date: Fri, 9 Feb 2001 20:10:08 GMT
Date: Fri, 9 Feb 2001 12:00:37 -0800
From: "Roy T. Fielding" <fielding@ebuilt.com>
To: Larry Masinter <LMM@acm.org>
Cc: Melman Howard <Howard@silverstream.com>, 
    HTTP WG <http-wg@cuckoo.hpl.hp.com>, 
    Joris Dobbelsteen <joris.dobbelsteen@mail.com>, 
    Paul Leach <paulle@exchange.microsoft.com>
Subject: Re: can charsets be quoted.
Message-ID: <20010209120037.C822@waka.ebuilt.net>
References: <14978.59949.384000.21123@gargle.gargle.HOWL> <NDBBKEBDLFENBJCGFOIJMEENEGAA.LMM@acm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13-current-20010115i
In-Reply-To: <NDBBKEBDLFENBJCGFOIJMEENEGAA.LMM@acm.org>; from LMM@acm.org on Fri, Feb 09, 2001 at 09:53:09AM -0800
Resent-Message-ID: <"Hn66S2.0.BG4.Zu4Xw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1020
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

> Hopefully this will get on the "errata" page...

Why?  The spec is correct.  It takes a great deal of imagination
to believe that the use of the word token in the text should somehow imply
that the HTTP syntax excludes a quoted-string.  Any token can appear inside
a quoted string.

....Roy


From Howard@silverstream.com Fri Feb  9 12:46:31 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa29115 ; 9 Feb 2001 12:46 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa22840 ; 9 Feb 2001 12:46 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id UAA02499;
	Fri, 9 Feb 2001 20:45:39 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id UAA18048; Fri, 9 Feb 2001 20:45:23 GMT
Resent-Date: Fri, 9 Feb 2001 20:45:23 GMT
From: "Melman, Howard" <Howard@silverstream.com>
To: "Roy T. Fielding" <fielding@ebuilt.com>
Cc: Larry Masinter <LMM@acm.org>, "Melman, Howard" <Howard@silverstream.com>, 
    HTTP WG <http-wg@cuckoo.hpl.hp.com>, 
    Joris Dobbelsteen <joris.dobbelsteen@mail.com>, 
    Paul Leach <paulle@exchange.microsoft.com>
X-Mailer: emacs 20.6.1 (via feedmail 8 I);
	VM 6.90 under Emacs 20.6.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14980.22031.111000.310785@gargle.gargle.HOWL>
Date: Fri, 9 Feb 2001 15:41:51 -0500
Subject: Re: can charsets be quoted.
In-Reply-To: <20010209120037.C822@waka.ebuilt.net>
References: <14978.59949.384000.21123@gargle.gargle.HOWL>
	<NDBBKEBDLFENBJCGFOIJMEENEGAA.LMM@acm.org>
	<20010209120037.C822@waka.ebuilt.net>
Resent-Message-ID: <"MqlxC3.0.HP4.ZP5Xw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1021
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


On Friday Feb 9, 2001, Roy T. Fielding wrote:

> > Hopefully this will get on the "errata" page...
> 
> Why?  The spec is correct.  It takes a great deal of imagination
> to believe that the use of the word token in the text should somehow imply
> that the HTTP syntax excludes a quoted-string.  Any token can appear inside
> a quoted string.

Perhaps, but it's not just the word "token" in text.  There
seems to be an ABNF rule in the section which as near as I
can tell adds no value to the description and does add
confusion.  Below is the text of section 3.4:

Howard

================================================================
3.4 Character Sets

   HTTP uses the same definition of the term "character set" as that
   described for MIME:

   The term "character set" is used in this document to refer to a
   method used with one or more tables to convert a sequence of octets
   into a sequence of characters. Note that unconditional conversion in
   the other direction is not required, in that not all characters may
   be available in a given character set and a character set may provide
   more than one sequence of octets to represent a particular character.
   This definition is intended to allow various kinds of character
   encoding, from simple single-table mappings such as US-ASCII to
   complex table switching methods such as those that use ISO-2022's
   techniques. However, the definition associated with a MIME character
   set name MUST fully specify the mapping to be performed from octets
   to characters. In particular, use of external profiling information
   to determine the exact mapping is not permitted.

      Note: This use of the term "character set" is more commonly
      referred to as a "character encoding." However, since HTTP and
      MIME share the same registry, it is important that the terminology
      also be shared.

   HTTP character sets are identified by case-insensitive tokens. The
   complete set of tokens is defined by the IANA Character Set registry
   [19].

       charset = token

   Although HTTP allows an arbitrary token to be used as a charset
   value, any token that has a predefined value within the IANA
   Character Set registry [19] MUST represent the character set defined
   by that registry. Applications SHOULD limit their use of character
   sets to those defined by the IANA registry.

   Implementors should be aware of IETF character set requirements [38]
   [41].


From fred569us@yahoo.com Mon Feb 12 12:49:11 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa19554 ; 12 Feb 2001 12:48 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa10535 ; 12 Feb 2001 12:47 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id UAA01007;
	Mon, 12 Feb 2001 20:45:48 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id UAA19331; Mon, 12 Feb 2001 20:45:33 GMT
Resent-Date: Mon, 12 Feb 2001 20:45:33 GMT
Message-ID: <20010212204224.70850.qmail@web10511.mail.yahoo.com>
Date: Mon, 12 Feb 2001 12:42:24 -0800 (PST)
From: fred doh <fred569us@yahoo.com>
Subject: Force chunked transfer-encoding?
To: http-wg@cuckoo.hpl.hp.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Resent-Message-ID: <"3T3t-1.0.ij4.oh4Yw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1022
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

Is there a way, issuing an HTTP 1.1 GET request to
force the response to be chunked, and also to ensure a
a maximum size for each chunk?

__fred



__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/


From francis@ecal.com Mon Feb 12 14:03:09 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa28710 ; 12 Feb 2001 14:03 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa02551 ; 12 Feb 2001 14:02 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id WAA03858;
	Mon, 12 Feb 2001 22:01:56 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id WAA20016; Mon, 12 Feb 2001 22:01:40 GMT
Resent-Date: Mon, 12 Feb 2001 22:01:40 GMT
Sender: francis@localhost.localdomain
Message-ID: <3A885DDC.A03B44CF@ecal.com>
Date: Mon, 12 Feb 2001 17:04:12 -0500
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586)
X-Accept-Language: en, de, es
MIME-Version: 1.0
To: http-wg@cuckoo.hpl.hp.com
Subject: Re: Force chunked transfer-encoding?
References: <20010212204224.70850.qmail@web10511.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"EFVDn2.0.Cu4.Bp5Yw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1023
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

fred doh wrote:

> Is there a way, issuing an HTTP 1.1 GET request to
> force the response to be chunked, and also to ensure a
> a maximum size for each chunk?

No.  Even if 1.1 has such a mechanism, you might be talking to a
1.0 server.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Don't anthropomorphize computers. We don't like|
|francis@ecal.com|it.                                            |
\================================================================/




From kugler@us.ibm.com Mon Feb 12 14:21:22 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa01891 ; 12 Feb 2001 14:21 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa07358 ; 12 Feb 2001 14:21 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id WAA04468;
	Mon, 12 Feb 2001 22:20:17 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id WAA20390; Mon, 12 Feb 2001 22:20:01 GMT
Resent-Date: Mon, 12 Feb 2001 22:20:01 GMT
Importance: Normal
Subject: Re: Force chunked transfer-encoding?
To: fred doh <fred569us@yahoo.com>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF793C7493.6F6C904D-ON872569F1.007A143E@LocalDomain>
From: Carl Kugler <kugler@us.ibm.com>
Date: Mon, 12 Feb 2001 15:15:57 -0700
X-MIMETrack: Serialize by Router on D03NM103/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 02/12/2001 03:15:59 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Resent-Message-ID: <"EqB5k.0.hz4.K46Yw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1024
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


You can use the TE request-header to indicate what transfer-codings you are
willing to accept.  However, there is no means to limit the chunk size.

     -Carl



fred doh <fred569us@yahoo.com> on 02/12/2001 01:42:24 PM

To:   http-wg@cuckoo.hpl.hp.com
cc:
Subject:  Force chunked transfer-encoding?



Is there a way, issuing an HTTP 1.1 GET request to
force the response to be chunked, and also to ensure a
a maximum size for each chunk?

__fred



__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year!  http://personal.mail.yahoo.com/





From LMM@acm.org Mon Feb 12 17:15:42 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa25150 ; 12 Feb 2001 17:15 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa25654 ; 12 Feb 2001 17:15 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id BAA10440;
	Tue, 13 Feb 2001 01:14:29 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id BAA21445; Tue, 13 Feb 2001 01:14:14 GMT
Resent-Date: Tue, 13 Feb 2001 01:14:14 GMT
From: Larry Masinter <LMM@acm.org>
To: HTTP WG <http-wg@cuckoo.hpl.hp.com>
Subject: RE: can charsets be quoted.
Date: Mon, 12 Feb 2001 11:09:02 -0800
Message-ID: <NDBBKEBDLFENBJCGFOIJGEIJEGAA.LMM@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <14980.22031.111000.310785@gargle.gargle.HOWL>
Resent-Message-ID: <"WB_ws3.0.ME5.gd8Yw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1025
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

"Although HTTP allows an arbitrary token to be used as a charset value"

It would be useful to clarify that HTTP uses charset in two contexts:
within an Accept-Charset request header (in which the charset value
is an unquoted token) and as the value of a parameter in a Content-type
header (within a request or response), in which case the parameter
value of the charset parameter may be quoted.

Larry
-- 
http://larry.masinter.net


From koen@hep.caltech.edu Thu Feb 15 22:44:51 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa11393 ; 15 Feb 2001 22:44 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa26539 ; 15 Feb 2001 22:44 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id GAA29278;
	Fri, 16 Feb 2001 06:43:30 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id GAA04577; Fri, 16 Feb 2001 06:43:15 GMT
Resent-Date: Fri, 16 Feb 2001 06:43:15 GMT
Date: Thu, 15 Feb 2001 22:39:42 -0800 (PST)
From: Koen Holtman <koen@hep.caltech.edu>
To: www-talk@w3.org
cc: Koen Holtman <koen@hep.caltech.edu>, http-wg@cuckoo.hpl.hp.com
Subject: Comments on `Common User Agent Problems' document
Message-ID: <Pine.A41.4.10.10102152237480.33242-100000@hep505.cithep.caltech.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"H7qye2.0.c61.6kCZw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1026
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


First off, thanks to the authors and the W3C for writing documents
like this!

I have some comments on the current version of
http://www.w3.org/TR/2001/NOTE-cuap-20010206 , mainly about the HTTP and  
negotiation parts.  Quoted text below is from this current version of the 
note.


>1.11 Allow the user to bookmark negotiated resources.

This text makes content negotiation in HTTP sound straightforward,
which it is not.  Some more info for browser implementers who want to
support this would be nice.

The text fails to mention that bookmarking a particular version of a
negotiated resource is not always possible under HTTP semantics, because     
a) the particular version may not have its own URI and b) even if it does,
HTTP does not guarantee that the user agent will be informed of this.

HTTP/1.1 defines the Content-Location header field as the way for the
server to indicate the URI of the variant, and some servers do supply
this Content-Location when negotiation took place most of the time.
However, Content-Location is also used for some other things, and its
inclusion in a response does not necessarily mean that content
negotiation took place.  Under plain HTTP/1.x the user agent will have
to use heuristics to guess if negotiation took place.  RFC 2295
defines the `TCN' and `Alternates' header fields, the inclusion of
these in a response is a sure sign that content negotiation did take
place.

RFC 2295 also specifies (section 11.2) that if a browser knows both
the generic URI and the variant URI, the defaults for showing the URI
and bookmarking the URI should be that the generic, not the variant,
URI is used.


>1.12 Allow the user to choose among supported transfer encodings. 

I think that what you _want_ to say here is that user agents should
try to support as many time-saving transfer encoding mechanisms
(compression, delta-encoding) as possible, and send out TE headers
announcing their support.

User control over this is unnecessary.  The HTTP/1.1 transfer encoding
negotiation mechanism was designed to avoid the need for the end user
to get involved.  Using the HTTP protocol, the server, proxy, and
client implementations among themselves will be able to choose and use
the most efficient transfer encoding.  Some power users might have
enough knowledge to fine-tune this process beyond what can be done
automatically, if their browsers provide an interface for this, but
that would be a very small group of users indeed.


>1.13 Use the user interface language as the default value for language
      negotiation. 

>In case the user does not specify any language, the user agent may use
>the language of its user interface as the value sent out.

This is wrong: a user agent should never automatically configure
itself to send out a single language value without asking for user
approval, because in HTTP semantics sending a single language value
only may very easily block convenient access to content in all other
languages.

Case in point: On the Apache mailing list someone recently reported
seeing problems due to user agents being preconfigured to send out

 Accept-language: xy

(for some language xy).  In requests for a page with many language
variants, but not including xy, this (currently) causes Apache to drop
into a `pick a language' 406 error response.  This is the best option
under HTTP semantics but it confuses the user, who is not aware that
the user agent is preconfigured to send out this very restricted
accept-language, who will therefore not have a clue on how to correct
this, and was just expecting to see the English variant if xy were not
available.

So, I propose that the document be changed to read:

In case the user does not specify any language, the user agent may
specify the language of its user interface as the preferred language,
while allowing other languages with a lower preference, for example by
sending

 Accept-Language: dk, *;q=0.5


>3.4 Do not treat HTTP temporary redirects as permanent redirects. 

>The user should be able to bookmark, copy, or link to the original
>(persistent) URI or the result of a temporary redirect.
>
>Wrong: User agents usually show the user (in the user interface) the
>URI that is the result of a temporary (302 or 307) redirect, as they
>would do for a permanent (301) redirect.

I do not like this advice to depart from current practice in showing
the target URI of a 302 redirect.  Changing current practice creates
usability problems for existing web content.  Here is why: server-side
image maps, the maps with HTML like this:

 <A HREF="http://x.com/cgi-bin/imagemap/worldmap">
 <IMG SRC="worldmap.gif" ISMAP></A>

generate URLs like
http://your.server.name/cgi-bin/imagemap/worldmap?444,33 when clicked
(if I recall the syntax correctly).  With an image map the server side
there is a CGI script (or other component) that takes the coordinates
and translates them to the correct URL (say http://x.com/canada/)
corresponding to the part of the image clicked.  In all
implementations I have ever seen, the script uses a *302 code*
redirect (usually created through the Location: mechanism in the CGI
interface) to direct the user agent to http://x.com/canada/!!!
Following your proposal would mean that the ?444,33 URL, not the
Canada URL, is shown and bookmarked, whereas the Canada URL is both
more informative and generally more permanent!

So at least I would like the document to make an exception to the
above rule for 302 redirection where imagemaps are the source.  But
actually I'd rather see the whole rule dropped and current common
behavior declared correct.  Based on experience with clarifying and
evolving the redirection codes in the http-wg, I take the view that a
departure from existing practice should only be done by adding fresh
codes, not by `fixing' the semantics of existing ones.


>3.6 List only supported media types in an HTTP Accept header. 

See also my comments to 1.13.  There is a similar problem here: in
non-inline image requests the user agent should generally *not* block
the receipt of unsupported types by specifying an overly restrictive
Accept header.

According to HTTP semantics, if the user agent is willing to process
any type (e.g. by saving it, see your point 1.3) then the Accept
header should either be omitted entirely or include */*;q=X for some
low value X.  Omitting this */*;q=X if you are willing to save to disk
as last resort is simply bad HTTP, though most server implementations
will usually let you get away with it.

In Apache the negotiation module has enough workarounds for bad Accept
headers already, so I would not like to to see new classes of bad
Accept headers introduced.  Point 3.6 should be rewritten to talk
about inline image requests only, or extended to also cover the
necessary subtleties in non-image requests.


Koen.



From fielding@ebuilt.com Sat Mar  3 06:10:06 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa24547 for <hyper>;
          3 Mar 2001 06:10 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa25767
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 3 Mar 2001 06:09 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/8.8.6 HPLabs Bristol Relay) with ESMTP id OAA03375;
	Sat, 3 Mar 2001 14:08:21 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id OAA08433; Sat, 3 Mar 2001 14:08:10 GMT
Resent-Date: Sat, 3 Mar 2001 14:08:10 GMT
Date: Sat, 3 Mar 2001 05:50:52 -0800
From: "Roy T. Fielding" <fielding@ebuilt.com>
To: http-wg@cuckoo.hpl.hp.com
Subject: RFC 2616 errata: overspecified restriction on automatic redirects
Message-ID: <20010303055052.A1007@waka.ebuilt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13-current-20010115i
X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/)
Resent-Message-ID: <"tf7Do1.0.U32.pfFew"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1027
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

Sections 10.3.2 (301 Moved Permanently) contains the paragraph

   If the 301 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

which fails to consider that there are many other request methods
that are safe to automatically redirect, and further that the user agent
is able to make that determination based on the request method semantics.
In particular, the OPTIONS method is always safe to automatically redirect.
Unfortunately, the paragraph was written long before there was OPTIONS,
and was never updated to reflect the extensibility of methods.  The
same problem paragraph is found in sections 10.3.3 and 10.3.8.

The above should be replaced with

   If the 301 status code is received in response to a request method
   that is known to be "safe", as defined in section 9.1.1, then the
   request MAY be automatically redirected by the user agent without
   confirmation.  Otherwise, the user agent MUST NOT automatically
   redirect the request unless it is confirmed by the user, since the
   new URI might change the conditions under which the request was issued.

along with similar changes for sections 10.3.3 and 10.3.8.
It would also be helpful for each of the method definition sections
to specifically define whether or not the method is safe.
OPTIONS, GET, and HEAD are all safe in RFC 2616.
HTTP extensions like WebDAV define additional safe methods.

This change does not impact interoperability.

Cheers,

Roy T. Fielding, Chief Scientist, eBuilt, Inc.
                 2652 McGaw Avenue
                 Irvine, CA 92614-5840  fax:+1.949.609.0001
                 (fielding@ebuilt.com)  <http://www.eBuilt.com>

                 Chairman, The Apache Software Foundation
                 (fielding@apache.org)  <http://www.apache.org/>


From MSabin@interx.com Mon Mar 12 09:30:53 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa29345 for <hyper>;
          12 Mar 2001 09:30 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa25881
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 12 Mar 2001 09:30 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id RAA09990;
	Mon, 12 Mar 2001 17:27:41 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id RAA02689; Mon, 12 Mar 2001 17:27:26 GMT
Resent-Date: Mon, 12 Mar 2001 17:27:26 GMT
Message-ID: <69B15B675E99D411A4110008C786DA23DED6A7@exwest_01.interx.com>
From: Miles Sabin <MSabin@interx.com>
To: http-wg@cuckoo.hpl.hp.com
Subject: HTTP client abort detection ...
Date: Mon, 12 Mar 2001 17:20:43 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"DPk-Y1.0.xe.0QGhw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1028
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

I've been trying (unsuccessfully) to decide whether or not
RFC 2616 permits a server to interpret the receipt of a FIN on
the incoming-request side of it's connection to a client as a 
full client close ... allowing it to immediately stop any
request processing, and possibly avoid a RST due to the arrival 
of unwanted response data at the client.

Unfortunately I can't convice myself that this is safe. I can't
see anything in the spec which says a client isn't allowed to
send a request, then shutdown(fd, 1), and then still expect the
server to continue request processing and send a response.

Is there lore on this? Are clients within their rights behaving
in this way? Do any real clients behave this way? Are there any
servers out there which aggressively monitor for client closes
and abort connections in the way I described above?

Opinions most welcome.

Cheers,


Miles

-- 
Miles Sabin                               InterX
Internet Systems Architect                5/6 Glenthorne Mews
+44 (0)20 8817 4030                       London, W6 0LJ, England
msabin@interx.com                         http://www.interx.com/


From MSabin@interx.com Mon Mar 12 10:37:55 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa10780 for <hyper>;
          12 Mar 2001 10:37 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa09584
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 12 Mar 2001 10:37 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id SAA12274;
	Mon, 12 Mar 2001 18:36:55 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id SAA03562; Mon, 12 Mar 2001 18:36:39 GMT
Resent-Date: Mon, 12 Mar 2001 18:36:39 GMT
Message-ID: <69B15B675E99D411A4110008C786DA23DED6A9@exwest_01.interx.com>
From: Miles Sabin <MSabin@interx.com>
To: http-wg@cuckoo.hpl.hp.com
Subject: RE: HTTP client abort detection ...
Date: Mon, 12 Mar 2001 18:30:01 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"GyP6Z2.0.us.xQHhw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1029
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

Scott Lawrence wrote,
> Miles Sabin wrote:
> > I've been trying (unsuccessfully) to decide whether or not
> > RFC 2616 permits a server to interpret the receipt of a FIN
> > on the incoming-request side of it's connection to a client 
> > as a full client close ... 
>
> I think that it would have been poor form at best for the HTTP 
> WG to ignore the Tcp semantics in that way.  In fact, the 
> client is doing you a favor by sending the FIN as soon as it 
> knows it's done with that half-connection - the server can then 
> close its half right away even if it might otherwise have left 
> it open for persistence, perhaps suffering the time-wait 
> penalty when it times it out (if the client sends the first 
> FIN, then it has to hold the time-wait, and the server 
> doesn't).

If the connection is idle (ie. no pending response), then yes, 
certainly, the server can close immediately.

But it's not so clear if there's (part or all of) a response 
pending, in which case the FIN could be interpreted as only
implying that no more requests will be sent over the connection,
rather than that the client is no longer interested in the
response to the current one.

As far as I can make out the only place in RFC 2616 which has any 
bearing on this scenario is 4.4 Message Length,

  the transfer-length of that body is determined by one of the 
  following (in order of precedence):

  5. By the server closing the connection. (Closing the 
     connection cannot be used to indicate the end of a request 
     body, since that would leave no possibility for the server 
     to send back a response.)

which no more than hints that servers will typically treat the 
receipt of a FIN as an abort. In context it only really rules
out a client using shutdown(fd, 1) as a substitute for chunking
or Content-Length.

I'd be much happier if there were language along the lines of,

  To ensure a reliable response to a request in progress, a 
  client SHOULD keep the transport connection open in both 
  directions until the full response has been received. A client
  MAY close the connection earlier if it does not receive a
  timely response.

  A server SHOULD monitor the network connection for a close
  before or while it is transmitting the response. If the server
  sees the connection close, it SHOULD immediately cease 
  transmitting the response.

  (language pinched from 8.2.2 and elsewhere)

I'm sure the above is the intent, but I just can't see anything 
which confirms it.

Cheers,


Miles

-- 
Miles Sabin                               InterX
Internet Systems Architect                5/6 Glenthorne Mews
+44 (0)20 8817 4030                       London, W6 0LJ, England
msabin@interx.com                         http://www.interx.com/


From dmk@bell-labs.com Tue Mar 13 10:57:41 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa04012 ; 13 Mar 2001 10:57 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa25303 ; 13 Mar 2001 10:57 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id SAA23028;
	Tue, 13 Mar 2001 18:55:57 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id SAA15546; Tue, 13 Mar 2001 18:55:40 GMT
Resent-Date: Tue, 13 Mar 2001 18:55:40 GMT
Sender: dmk@research.bell-labs.com
Message-ID: <3AAE6BFD.4E13FC6F@bell-labs.com>
Date: Tue, 13 Mar 2001 13:50:37 -0500
From: Dave Kristol <dmk@bell-labs.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: HTTP Working Group <http-wg@hplb.hpl.hp.com>
Subject: about relative URLs
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"f4Tdk.0.nn3.hochw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1030
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

Is the following a valid relative HTTP URL?
	http:/mypath/index.html

The intended meaning is to GET the resource "/mypath/index.html" from the
current server (the one from which the page with this link was retrieved).

There has been some discussion regarding Mozilla
(<http://bugzilla.mozilla.org/show_bug.cgi?id=34648>), which gets confused by
this URL.  (That is, it doesn't do what I intended.)  RFC 1808 (Relative URLs)
accepts them syntactically, then gives "an example algorithm" that would reject
them (sect. 4):
=======
   Step 2: Both the base and embedded URLs are parsed into their
           component parts as described in Section 2.4.

           a) If the embedded URL is entirely empty, it inherits the
              entire base URL (i.e., is set equal to the base URL)
              and we are done.

>>         b) If the embedded URL starts with a scheme name, it is
              interpreted as an absolute URL and we are done.

           c) Otherwise, the embedded URL inherits the scheme of
              the base URL.
=======

RFC 2396, Sect. 5, implies that the example is not relative, via the negation of
"A relative reference that does not begin with a scheme name or a slash
character is termed a relative-path reference."  Section 5.2 more explicitly
says (like RFC 1808):
=======
   3) If the scheme component is defined, indicating that the reference
      starts with a scheme name, then the reference is interpreted as an
      absolute URI and we are done.  Otherwise, the reference URI's
      scheme is inherited from the base URI's scheme component.
=======

I guess I haven't been paying attention.  I have been using URLs like the
example for years, and they have been accepted (by liberal programs?). 
Furthermore, I don't see why the RFC so specifically declares all URLs with a
scheme to be absolute (except that Sect. 4 says "[t]he syntax for relative URI
is a shortened form of that for absolute URI, where some prefix of the URI is
missing...".  It seems to me that an otherwise relative URL with an explicit
scheme can be parsed unambiguously.

Dave Kristol


From ronald@innovation.ch Tue Mar 13 22:36:55 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa09626 ; 13 Mar 2001 22:36 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa13415 ; 13 Mar 2001 22:36 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id GAA07827;
	Wed, 14 Mar 2001 06:35:10 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id GAA25947; Wed, 14 Mar 2001 06:34:53 GMT
Resent-Date: Wed, 14 Mar 2001 06:34:53 GMT
Date: Tue, 13 Mar 2001 22:28:45 -0800
From: "Life is hard, and then you die" <ronald@innovation.ch>
To: Dave Kristol <dmk@bell-labs.com>
Cc: HTTP Working Group <http-wg@hplb.hpl.hp.com>
Subject: Re: about relative URLs
Message-ID: <20010313222844.B6374@innovation.ch>
Mail-Followup-To: Dave Kristol <dmk@bell-labs.com>,
	HTTP Working Group <http-wg@hplb.hpl.hp.com>
References: <3AAE6BFD.4E13FC6F@bell-labs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <3AAE6BFD.4E13FC6F@bell-labs.com>; from dmk@bell-labs.com on Tue, Mar 13, 2001 at 01:50:37PM -0500
Resent-Message-ID: <"tTQXX1.0.fK6.G2nhw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1031
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


  Hi Dave,

> Is the following a valid relative HTTP URL?
> 	http:/mypath/index.html

No.

> The intended meaning is to GET the resource "/mypath/index.html" from the
> current server (the one from which the page with this link was retrieved).
> 
> There has been some discussion regarding Mozilla
> (<http://bugzilla.mozilla.org/show_bug.cgi?id=34648>), which gets confused by
> this URL.  (That is, it doesn't do what I intended.)  RFC 1808 (Relative URLs)
> accepts them syntactically, then gives "an example algorithm" that would reject
> them (sect. 4):
[snip]
> RFC 2396, Sect. 5, implies that the example is not relative, via the negation of
> "A relative reference that does not begin with a scheme name or a slash
> character is termed a relative-path reference."  Section 5.2 more explicitly
> says (like RFC 1808):
> =======
>    3) If the scheme component is defined, indicating that the reference
>       starts with a scheme name, then the reference is interpreted as an
>       absolute URI and we are done.  Otherwise, the reference URI's
>       scheme is inherited from the base URI's scheme component.
> =======

The next paragraph after that is instructive:

      Due to a loophole in prior specifications [RFC1630], some parsers
      allow the scheme name to be present in a relative URI if it is the
      same as the base URI scheme.  Unfortunately, this can conflict
      with the correct parsing of non-hierarchical URI.  For backwards
      compatibility, an implementation may work around such references
      by removing the scheme if it matches that of the base URI and the
      scheme is known to always use the <hier_part> syntax.  The parser
      can then continue with the steps below for the remainder of the
      reference components.  Validating parsers should mark such a
      misformed relative reference as an error.

> I guess I haven't been paying attention.  I have been using URLs like the
> example for years, and they have been accepted (by liberal programs?). 
> Furthermore, I don't see why the RFC so specifically declares all URLs with a
> scheme to be absolute (except that Sect. 4 says "[t]he syntax for relative URI
> is a shortened form of that for absolute URI, where some prefix of the URI is
> missing...".  It seems to me that an otherwise relative URL with an explicit
> scheme can be parsed unambiguously.

One of the authors will have to give you the details on the thoughts that
went behind this, but <scheme>:<abs_path> (ala http:/mypath/index.html)
is a valid absolute URI (not for http, but in general for URI's
following the generic syntax), and hence a generic syntax parser would
be unable to distinguish between relative and absolute URI's. There's no
reason to allow relative URI's of the form <scheme>:<abs_path> (other
than backwards compatibility), but there is for absolute URI's (e.g. the
file scheme doesn't need any host part).


  Cheers,

  Ronald


From MSabin@interx.com Wed Mar 14 06:43:32 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa03150 ; 14 Mar 2001 06:43 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa12109 ; 14 Mar 2001 06:43 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id OAA23395;
	Wed, 14 Mar 2001 14:41:43 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id OAA27129; Wed, 14 Mar 2001 14:41:29 GMT
Resent-Date: Wed, 14 Mar 2001 14:41:29 GMT
Message-ID: <69B15B675E99D411A4110008C786DA23DED6CE@exwest_01.interx.com>
From: Miles Sabin <MSabin@interx.com>
To: http-wg@cuckoo.hpl.hp.com
Subject: HTTP and half close (WAS: HTTP client abort detection)
Date: Wed, 14 Mar 2001 14:35:00 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"Uz-Bz1.0.6d6.UAuhw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1032
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

Scott Lawrence wrote,
> Miles Sabin wrote:
> > I've been trying (unsuccessfully) to decide whether or not
> > RFC 2616 permits a server to interpret the receipt of a FIN 
> > on the incoming-request side of it's connection to a client 
> > as a full client close ... 
>
> I think that it would have been poor form at best for the HTTP 
> WG to ignore the Tcp semantics in that way.  In fact, the 
> client is doing you a favor by sending the FIN as soon as it 
> knows it's done with that half-connection - the server can then 
> close its half right away even if it might otherwise have left 
> it open for persistence, perhaps suffering the time-wait 
> penalty when it times it out (if the client sends the first 
> FIN, then it has to hold the time-wait, and the server 
> doesn't).

Thinking about this some more, I'm coming to the conclusion that
there's a genuine and problematic gap in RFC 2616. Just to make 
sure there's no misunderstanding here, I want to emphasize that 
I'm quite well aware of the benefits for servers of clients 
sending the first FIN.

As far as I can make out there's nothing in RFC 2616 which 
unambiguously rules out any of the following possible client and 
server implementations,

1. Clients which send a FIN early ... ie. by doing a half close
   as soon as their last request is sent, but possibly before
   the corresponding response has been received.

2. Clients which don't (half or full) close until all pending
   responses have been received.

A. Servers which treat an early client FIN only as a half close 
   and continue processing and sending pending responses.

B. Servers which treat an early client FIN as an indicator of a 
   client abort, and hence abandon processing and sending pending
   responses.

The problem is that clients of type 1 aren't fully interoperable
with servers of type B ... if a type 1 client does an eager
half close a type B server would abandon it's response.

So at least one of these two should be ruled out by RFC 2616. 

Unfortunately I don't see that either unambiguously is. And if
neither are ruled out by the spec, then interoperability
considerations mean that it's not safe for client or server
implementors to adopt either. In real-world terms, I'm pretty
sure that most existing user-agents (nb. I'm not talking about 
clients generally) are of type 2, and most servers are of type
A.

Here are some pro and con considerations wrt type 1 clients and
type B servers.

* The pragmatic good citizenship argument that a client should 
  send the first FIN, and sending it immediately after its 
  request has been sent, before any or all of the response has 
  been received, makes that likely.

  On the other hand, this isn't the only way for a client to send
  the first FIN. In scenarios which allow a client to half close
  eagerly it should also be possible for it to send Connection: 
  close, in which case the server would know that the connection 
  is terminating. Hence the server, assuming it sends a Content-
  Length or chunks, could quite happily defer closing after 
  sending the response, on the assumption that the client will 
  close soon and that it can close it's own end when that
  happens.

  On balance, I don't think any conclusion can be drawn from the
  above. Early half close helps servers, but there are other
  ways of getting the same effect.

* A similar pragmatic argument that if servers are allowed to
  treat early client FINs as client aborts, then they might be
  able to avoid expensive response processing.

  In the particular case of a proxy server, such a FIN might be 
  detected during proxy-side DNS resolution, but before the 
  initiation of a connect to an origin server. If the proxy 
  isn't going to cache the now unwanted response (either because 
  it's not a caching proxy, or because it's confident the 
  response will be uncacheable) then it would make sense not to 
  attempt to forward the request to the origin server at all.

* From 8.1.4 Practical Considerations,

    Servers SHOULD always respond to at least one request per 
    connection, if at all possible. Servers SHOULD NOT close a 
    connection in the middle of transmitting a response, unless a 
    network or client failure is suspected.

  So long as we read 'middle' of a response liberally and allow 
  it to cover any point in time between the servers receipt of
  the request up to the completion of the sending of the 
  response, then this seems to support type 1 clients against 
  type B servers.

  Nevertheless, it's very hard to see the practical difference
  between a 'network or client failure' and, say, the behaviour
  of a user agent when a user hits the stop button because the
  server hasn't managed to deliver a response sufficiently
  quickly.

* If we aren't so liberal with the reading of 'middle' in the
  above quoted para, then we have,

    A client, server, or proxy MAY close the transport connection 
    at any time. For example, a client might have started to send 
    a new request at the same time that the server has decided to 
    close the "idle" connection. From the server's point of view, 
    the connection is being closed while it was idle, but from 
    the client's point of view, a request is in progress.

  This suggests that a server which detects an early client FIN 
  would be within it's rights in exploiting the persistent 
  connection close race condition to avoid processing or sending 
  any response at all: it's free to close the connection at any 
  time, and it's not yet started to send it's response. The only 
  difference between this scenario and the typical cases is the 
  exact location of the request message ... on the wire, in the 
  TCP receive buffers, or in a server buffer.

* If type 1 clients are legitimate, this parenthetical comment in 
  4.4 Message Length becomes quite baffling,

    the transfer-length of that body is determined by one of the 
    following (in order of precedence):

    5. By the server closing the connection. (Closing the 
       connection cannot be used to indicate the end of a request 
       body, since that would leave no possibility for the server 
       to send back a response.)

  because if an early half-close were legitimate, it would
  provide a perfectly respectable mechanism for delimiting a
  request body.

None of the above leaves me with any particularly clear idea of
what best practice might be. Unless I can be persuaded otherwise
I'm obliged to be cautious from an interoperability perspective
and assume,

* That a type 1 client implementation is inadvisable, because
  it wouldn't reliably interoperate with type B servers.

* That a type B server implementation is inadvisable, because
  it wouldn't reliably interoperate with type 1 clients.

Can anyone shed any more light on this?

Cheers,


Miles

-- 
Miles Sabin                               InterX
Internet Systems Architect                5/6 Glenthorne Mews
+44 (0)20 8817 4030                       London, W6 0LJ, England
msabin@interx.com                         http://www.interx.com/


From kugler@us.ibm.com Wed Mar 14 08:03:04 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa17595 ; 14 Mar 2001 08:03 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa05889 ; 14 Mar 2001 08:02 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id QAA26709;
	Wed, 14 Mar 2001 16:01:52 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id QAA28075; Wed, 14 Mar 2001 16:01:37 GMT
Resent-Date: Wed, 14 Mar 2001 16:01:37 GMT
Importance: Normal
Subject: Re: HTTP and half close (WAS: HTTP client abort detection)
To: Miles Sabin <MSabin@interx.com>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: <OF99DF2538.169E640E-ON87256A0F.00573C13@LocalDomain>
From: Carl Kugler <kugler@us.ibm.com>
Date: Wed, 14 Mar 2001 08:57:52 -0700
X-MIMETrack: Serialize by Router on D03NM103/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 03/14/2001 08:57:53 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Resent-Message-ID: <"7v_Sj1.0.Kr6.RLvhw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1033
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


There is a long-expired Internet-Draft, "HTTP Connection Management"
(http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt),
that has some good discussion of related issues.

<!--StartFragment-->The HTTP/1.1 Proposed Standard [HTTP/1.1] specification
is silent on
   when, or even if, the connection should be closed (implementation
   experience was desired before the specification was frozen on this
   topic). So HTTP has moved from a model that closed the connection
   after every request/response to one that might never close. Neither
   of these two extremes deal with "connection management" in any
   workable sense.
<!--EndFragment-->

     -Carl



Miles Sabin <MSabin@interx.com> on 03/14/2001 07:35:00 AM

To:   http-wg@cuckoo.hpl.hp.com
cc:
Subject:  HTTP and half close (WAS: HTTP client abort detection)



Scott Lawrence wrote,
> Miles Sabin wrote:
> > I've been trying (unsuccessfully) to decide whether or not
> > RFC 2616 permits a server to interpret the receipt of a FIN
> > on the incoming-request side of it's connection to a client
> > as a full client close ...
>
> I think that it would have been poor form at best for the HTTP
> WG to ignore the Tcp semantics in that way.  In fact, the
> client is doing you a favor by sending the FIN as soon as it
> knows it's done with that half-connection - the server can then
> close its half right away even if it might otherwise have left
> it open for persistence, perhaps suffering the time-wait
> penalty when it times it out (if the client sends the first
> FIN, then it has to hold the time-wait, and the server
> doesn't).

Thinking about this some more, I'm coming to the conclusion that
there's a genuine and problematic gap in RFC 2616. Just to make
sure there's no misunderstanding here, I want to emphasize that
I'm quite well aware of the benefits for servers of clients
sending the first FIN.

As far as I can make out there's nothing in RFC 2616 which
unambiguously rules out any of the following possible client and
server implementations,

1. Clients which send a FIN early ... ie. by doing a half close
   as soon as their last request is sent, but possibly before
   the corresponding response has been received.

2. Clients which don't (half or full) close until all pending
   responses have been received.

A. Servers which treat an early client FIN only as a half close
   and continue processing and sending pending responses.

B. Servers which treat an early client FIN as an indicator of a
   client abort, and hence abandon processing and sending pending
   responses.

The problem is that clients of type 1 aren't fully interoperable
with servers of type B ... if a type 1 client does an eager
half close a type B server would abandon it's response.

So at least one of these two should be ruled out by RFC 2616.

Unfortunately I don't see that either unambiguously is. And if
neither are ruled out by the spec, then interoperability
considerations mean that it's not safe for client or server
implementors to adopt either. In real-world terms, I'm pretty
sure that most existing user-agents (nb. I'm not talking about
clients generally) are of type 2, and most servers are of type
A.

Here are some pro and con considerations wrt type 1 clients and
type B servers.

* The pragmatic good citizenship argument that a client should
  send the first FIN, and sending it immediately after its
  request has been sent, before any or all of the response has
  been received, makes that likely.

  On the other hand, this isn't the only way for a client to send
  the first FIN. In scenarios which allow a client to half close
  eagerly it should also be possible for it to send Connection:
  close, in which case the server would know that the connection
  is terminating. Hence the server, assuming it sends a Content-
  Length or chunks, could quite happily defer closing after
  sending the response, on the assumption that the client will
  close soon and that it can close it's own end when that
  happens.

  On balance, I don't think any conclusion can be drawn from the
  above. Early half close helps servers, but there are other
  ways of getting the same effect.

* A similar pragmatic argument that if servers are allowed to
  treat early client FINs as client aborts, then they might be
  able to avoid expensive response processing.

  In the particular case of a proxy server, such a FIN might be
  detected during proxy-side DNS resolution, but before the
  initiation of a connect to an origin server. If the proxy
  isn't going to cache the now unwanted response (either because
  it's not a caching proxy, or because it's confident the
  response will be uncacheable) then it would make sense not to
  attempt to forward the request to the origin server at all.

* From 8.1.4 Practical Considerations,

    Servers SHOULD always respond to at least one request per
    connection, if at all possible. Servers SHOULD NOT close a
    connection in the middle of transmitting a response, unless a
    network or client failure is suspected.

  So long as we read 'middle' of a response liberally and allow
  it to cover any point in time between the servers receipt of
  the request up to the completion of the sending of the
  response, then this seems to support type 1 clients against
  type B servers.

  Nevertheless, it's very hard to see the practical difference
  between a 'network or client failure' and, say, the behaviour
  of a user agent when a user hits the stop button because the
  server hasn't managed to deliver a response sufficiently
  quickly.

* If we aren't so liberal with the reading of 'middle' in the
  above quoted para, then we have,

    A client, server, or proxy MAY close the transport connection
    at any time. For example, a client might have started to send
    a new request at the same time that the server has decided to
    close the "idle" connection. From the server's point of view,
    the connection is being closed while it was idle, but from
    the client's point of view, a request is in progress.

  This suggests that a server which detects an early client FIN
  would be within it's rights in exploiting the persistent
  connection close race condition to avoid processing or sending
  any response at all: it's free to close the connection at any
  time, and it's not yet started to send it's response. The only
  difference between this scenario and the typical cases is the
  exact location of the request message ... on the wire, in the
  TCP receive buffers, or in a server buffer.

* If type 1 clients are legitimate, this parenthetical comment in
  4.4 Message Length becomes quite baffling,

    the transfer-length of that body is determined by one of the
    following (in order of precedence):

    5. By the server closing the connection. (Closing the
       connection cannot be used to indicate the end of a request
       body, since that would leave no possibility for the server
       to send back a response.)

  because if an early half-close were legitimate, it would
  provide a perfectly respectable mechanism for delimiting a
  request body.

None of the above leaves me with any particularly clear idea of
what best practice might be. Unless I can be persuaded otherwise
I'm obliged to be cautious from an interoperability perspective
and assume,

* That a type 1 client implementation is inadvisable, because
  it wouldn't reliably interoperate with type B servers.

* That a type B server implementation is inadvisable, because
  it wouldn't reliably interoperate with type 1 clients.

Can anyone shed any more light on this?

Cheers,


Miles

--
Miles Sabin                               InterX
Internet Systems Architect                5/6 Glenthorne Mews
+44 (0)20 8817 4030                       London, W6 0LJ, England
msabin@interx.com                         http://www.interx.com/





From MSabin@interx.com Wed Mar 14 08:21:16 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa20792 ; 14 Mar 2001 08:21 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa11237 ; 14 Mar 2001 08:21 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id QAA27512;
	Wed, 14 Mar 2001 16:20:15 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id QAA28647; Wed, 14 Mar 2001 16:19:58 GMT
Resent-Date: Wed, 14 Mar 2001 16:19:58 GMT
Message-ID: <69B15B675E99D411A4110008C786DA23DED6D4@exwest_01.interx.com>
From: Miles Sabin <MSabin@interx.com>
To: http-wg@cuckoo.hpl.hp.com
Subject: RE: HTTP and half close (WAS: HTTP client abort detection)
Date: Wed, 14 Mar 2001 16:13:36 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"3j_c_.0.p-6.rcvhw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1034
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

Carl Kugler wrote,
> There is a long-expired Internet-Draft, "HTTP Connection 
> Management"
<snip/>
> that has some good discussion of related issues.

Yup, I'm aware of that doc. Unfortunately it only addresses the
question of when a *server* should do a half close and why, not
when or if a *client* should half close.

Cheers,


Miles

-- 
Miles Sabin                               InterX
Internet Systems Architect                5/6 Glenthorne Mews
+44 (0)20 8817 4030                       London, W6 0LJ, England
msabin@interx.com                         http://www.interx.com/


From fielding@ebuilt.com Fri Mar 16 17:54:59 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa02074 ; 16 Mar 2001 17:54 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa19933 ; 16 Mar 2001 17:54 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id BAA02037;
	Sat, 17 Mar 2001 01:52:56 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id BAA22282; Sat, 17 Mar 2001 01:52:39 GMT
Resent-Date: Sat, 17 Mar 2001 01:52:39 GMT
Date: Fri, 16 Mar 2001 17:33:55 -0800
From: "Roy T. Fielding" <fielding@ebuilt.com>
To: Miles Sabin <MSabin@interx.com>
Cc: http-wg@cuckoo.hpl.hp.com
Subject: Re: HTTP and half close (WAS: HTTP client abort detection)
Message-ID: <20010316173355.C1008@waka.ebuilt.net>
References: <69B15B675E99D411A4110008C786DA23DED6CE@exwest_01.interx.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13-current-20010115i
In-Reply-To: <69B15B675E99D411A4110008C786DA23DED6CE@exwest_01.interx.com>; from MSabin@interx.com on Wed, Mar 14, 2001 at 02:35:00PM -0000
X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/)
Resent-Message-ID: <"gOSOi2.0.tR5.hBiiw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1035
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

"Server receives a FIN" and "HTTP connection is closed" are two
different things.  The first is one part of a TCP handshake for which
HTTP has no business defining the rules (HTTP is transport independent),
and the second is something that an application has to find out from
whatever network API it is using for sending/receiving HTTP bytes.

Using the typical socket API with TCP, an HTTP connection is considered
to be closed when it receives a fatal error or EOF either:

   1) when attempting to read an unfinished request and there are
      no pending responses being sent on the connection (this is easily
      determined because all HTTP requests are length-delimited), or

   2) when writing a response.

Note that the above applies to the socket API.  There may be a completely
different algorithm for determining when the connection is closed when
using other API, particularly event-based ones.

The reason this isn't defined in the HTTP spec is because it is not
an interoperability issue for the application protocol -- it is an
implementation detail that is entirely dependent on the nature of the
lower-layer API used by the application.  It is the stuff for a good
book on network programming.

BTW, the reason that clients don't close the connection is because
they are generally written to be selfish in regard to network resources.
Some clients (Windows-based) never send a FIN -- they always do an RST
because they don't want to incur the cost of TIME_WAIT, due to an
unusually low fixed limit on mbufs for some version of the OS.  This is
broken behavior, since the RST is easily lost and the server is left
hanging til a timeout expires, but that is fairly typical of clients.


Cheers,

Roy T. Fielding, Chief Scientist, eBuilt, Inc.
                 2652 McGaw Avenue
                 Irvine, CA 92614-5840  fax:+1.949.609.0001
                 (fielding@ebuilt.com)  <http://www.eBuilt.com>


From MSabin@interx.com Sat Mar 17 01:45:24 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa23933 ; 17 Mar 2001 01:45 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa13678 ; 17 Mar 2001 01:45 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id JAA08894;
	Sat, 17 Mar 2001 09:44:20 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id JAA02406; Sat, 17 Mar 2001 09:44:02 GMT
Resent-Date: Sat, 17 Mar 2001 09:44:02 GMT
Message-ID: <69B15B675E99D411A4110008C786DA23DED728@exwest_01.interx.com>
From: Miles Sabin <MSabin@interx.com>
To: http-wg@cuckoo.hpl.hp.com
Subject: RE: HTTP and half close (WAS: HTTP client abort detection)
Date: Sat, 17 Mar 2001 09:37:30 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"TRxR33.0.pa.c5piw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1036
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

Roy T. Fielding wrote,
> Using the typical socket API with TCP, an HTTP connection is 
> considered to be closed when it receives a fatal error or EOF 
> either:
>
>  1) when attempting to read an unfinished request and there 
>     are no pending responses being sent on the connection 
>     (this is easily determined because all HTTP requests are 
>     length-delimited), or
>
>  2) when writing a response.

So, in other words, the type 1 clients of my previous posting
(early half close) are correct, and the type B servers of my
previous posting (early EOF implies client abort) are incorrect.

That's all very well, but it's only one of the possible choices 
for the mapping of TCP/socket API behaviour on to HTTP behaviour.
It'd be nice to have some justification for why the choice should 
be made this way rather than some other, and some reassurance 
that this is the way the choice has been made in real 
implementations. 

It also leaves me puzzled about the question of delimiting
request entities. If a client TCP half close *isn't* considered 
as an HTTP connection close, then why can't we use that that as 
an alternative to Content-Length or chunking? Given what you've
said above, the parenthesis in,

   5.By the server closing the connection. (Closing the 
     connection cannot be used to indicate the end of a request 
     body, since that would leave no possibility for the server 
     to send back a response.)

simply doesn't apply. Why not allow EOF as a request entity
delimiter?

> Note that the above applies to the socket API.  There may be a 
> completely different algorithm for determining when the 
> connection is closed when using other API, particularly event-
> based ones.

Could you elaborate on this? It seems to imply that we might
have client and server HTTP over TCP implementations, one built 
on the socket API, one built on something else, each with
different mappings of TCP behaviour to HTTP behaviour, hence that 
the two might not be fully interoperable. I'm not sufficiently 
familiar with non-socket APIs to say whether this would be likely 
to be a problem in practice, but it certainly seems like a 
worrying prospect.

> The reason this isn't defined in the HTTP spec is because it is 
> not an interoperability issue for the application protocol -- 
> it is an implementation detail that is entirely dependent on 
> the nature of the lower-layer API used by the application.  It 
> is the stuff for a good book on network programming.

Perhaps it's not an issue for the abstract protocol, but it is
an issue for it's most common concrete realization. Isn't this
sort of interaction between the transport layer and the
application layer precisely the sort of thing which prompted
Jim Gettys and Alan Freiers "HTTP Connection Management" ID?

On the face of it, it'd be useful to have one or more transport
layer specific profiles as adjuncts to the abstract protocol
specification.

Cheers,


Miles

-- 
Miles Sabin                               InterX
Internet Systems Architect                5/6 Glenthorne Mews
+44 (0)20 8817 4030                       London, W6 0LJ, England
msabin@interx.com                         http://www.interx.com/


From fielding@ebuilt.com Sat Mar 17 23:23:48 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa12496 ; 17 Mar 2001 23:23 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa13991 ; 17 Mar 2001 23:23 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id HAA26440;
	Sun, 18 Mar 2001 07:21:57 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id HAA12727; Sun, 18 Mar 2001 07:21:42 GMT
Resent-Date: Sun, 18 Mar 2001 07:21:42 GMT
Date: Sat, 17 Mar 2001 23:03:28 -0800
From: "Roy T. Fielding" <fielding@ebuilt.com>
To: Miles Sabin <MSabin@interx.com>
Cc: http-wg@cuckoo.hpl.hp.com
Subject: Re: HTTP and half close (WAS: HTTP client abort detection)
Message-ID: <20010317230328.A914@waka.ebuilt.net>
References: <69B15B675E99D411A4110008C786DA23DED728@exwest_01.interx.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13-current-20010115i
In-Reply-To: <69B15B675E99D411A4110008C786DA23DED728@exwest_01.interx.com>; from MSabin@interx.com on Sat, Mar 17, 2001 at 09:37:30AM -0000
X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/)
Resent-Message-ID: <"zj-oE2.0.863.766jw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1037
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

> That's all very well, but it's only one of the possible choices 
> for the mapping of TCP/socket API behaviour on to HTTP behaviour.
> It'd be nice to have some justification for why the choice should 
> be made this way rather than some other, and some reassurance 
> that this is the way the choice has been made in real 
> implementations. 

There are literally millions of theoretical possibilties that are
not mentioned in a protocol spec.  If they were all mentioned, then
nobody would have time to read the spec.

The reasoning in this case is very simple: be conservative in what you
send and liberal in what you accept.  If you follow that principle, there
is only one choice, and you will find it in every robust implementation of
HTTP over TCP.  Go ahead and check the source code at apache.org.

> It also leaves me puzzled about the question of delimiting
> request entities. If a client TCP half close *isn't* considered 
> as an HTTP connection close, then why can't we use that that as 
> an alternative to Content-Length or chunking? Given what you've
> said above, the parenthesis in,
> 
>    5.By the server closing the connection. (Closing the 
>      connection cannot be used to indicate the end of a request 
>      body, since that would leave no possibility for the server 
>      to send back a response.)
> 
> simply doesn't apply. Why not allow EOF as a request entity
> delimiter?

Because there is no value obtained by allowing it, and the cost would be
to add an HTTP requirement that is specific to those TCP API that provide
half-close as an option.  If there exists a platform for which the
application-layer cannot discern a half-close condition from an error
condition, then the server on that platform cannot know if it has
received the entire request or only a partial request, and since this
can impact the fidelity of carrying out that request, you have defined
a protocol which is less robust than what is defined in RFC 2616.
Therefore, it is not an option allowed by HTTP/1.1.

> > Note that the above applies to the socket API.  There may be a 
> > completely different algorithm for determining when the 
> > connection is closed when using other API, particularly event-
> > based ones.
> 
> Could you elaborate on this? It seems to imply that we might
> have client and server HTTP over TCP implementations, one built 
> on the socket API, one built on something else, each with
> different mappings of TCP behaviour to HTTP behaviour, hence that 
> the two might not be fully interoperable. I'm not sufficiently 
> familiar with non-socket APIs to say whether this would be likely 
> to be a problem in practice, but it certainly seems like a 
> worrying prospect.

They are interoperable right now precisely because HTTP does not
define things in terms of TCP.  There are many platforms that have
HTTP servers without any TCP -- the Web was created in a world where
TCP was not the universal standard for transport (not that it is today).
The intermediary boxes that translate from non-TCP server network to
TCP client network do not know anything about HTTP, and thus an HTTP
message can only be sent through that gateway if neither side makes
implementation assumptions about the other beyond those carried within
the HTTP message.

> > The reason this isn't defined in the HTTP spec is because it is 
> > not an interoperability issue for the application protocol -- 
> > it is an implementation detail that is entirely dependent on 
> > the nature of the lower-layer API used by the application.  It 
> > is the stuff for a good book on network programming.
> 
> Perhaps it's not an issue for the abstract protocol, but it is
> an issue for it's most common concrete realization. Isn't this
> sort of interaction between the transport layer and the
> application layer precisely the sort of thing which prompted
> Jim Gettys and Alan Freiers "HTTP Connection Management" ID?
> 
> On the face of it, it'd be useful to have one or more transport
> layer specific profiles as adjuncts to the abstract protocol
> specification.

There is absolutely no question that there is value in documenting
implementation profiles for protocols.  I am particularly fond of the
ones written by W. Richard Stevens.  But there is also a damn good
reason why those profiles are better written by individual authors
rather than within a standards organization, and that is because they
deal with how a standard should be implemented rather than what the
standard should be.

Cheers,

Roy T. Fielding, Chief Scientist, eBuilt, Inc.
                 2652 McGaw Avenue
                 Irvine, CA 92614-5840  fax:+1.949.609.0001
                 (fielding@ebuilt.com)  <http://www.eBuilt.com>


From kugler@us.ibm.com Mon Mar 19 09:13:08 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa05099 ; 19 Mar 2001 09:13 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa17475 ; 19 Mar 2001 09:12 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id RAA06640;
	Mon, 19 Mar 2001 17:11:25 GMT
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id RAA24204; Mon, 19 Mar 2001 17:11:10 GMT
Resent-Date: Mon, 19 Mar 2001 17:11:10 GMT
Importance: Normal
Subject: RE: HTTP and half close (WAS: HTTP client abort detection)
To: Miles Sabin <MSabin@interx.com>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: <OF9E1DBBA7.BA694A78-ON87256A14.005D7A45@LocalDomain>
From: Carl Kugler <kugler@us.ibm.com>
Date: Mon, 19 Mar 2001 10:08:12 -0700
X-MIMETrack: Serialize by Router on D03NM103/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 03/19/2001 10:08:17 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Resent-Message-ID: <"IiiHp3.0.rv5.mqZjw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1038
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


Miles wrote:
>Roy T. Fielding wrote,
>> Using the typical socket API with TCP, an HTTP connection is
>> considered to be closed when it receives a fatal error or EOF
>> either:
>>
>>  1) when attempting to read an unfinished request and there
>>     are no pending responses being sent on the connection
>>     (this is easily determined because all HTTP requests are
>>     length-delimited), or
>>
>>  2) when writing a response.
>
>So, in other words, the type 1 clients of my previous posting
>(early half close) are correct, and the type B servers of my
>previous posting (early EOF implies client abort) are incorrect.
>
>That's all very well, but it's only one of the possible choices
>for the mapping of TCP/socket API behaviour on to HTTP behaviour.
>It'd be nice to have some justification for why the choice should
>be made this way rather than some other, and some reassurance
>that this is the way the choice has been made in real
>implementations.
>
>It also leaves me puzzled about the question of delimiting
>request entities. If a client TCP half close *isn't* considered
>as an HTTP connection close, then why can't we use that that as
>an alternative to Content-Length or chunking? Given what you've
>said above, the parenthesis in,
>
>   5.By the server closing the connection. (Closing the
>     connection cannot be used to indicate the end of a request
>     body, since that would leave no possibility for the server
>     to send back a response.)
>
>simply doesn't apply. Why not allow EOF as a request entity
>delimiter?
>

It was, in HTTP/1.0 or 0.9, wasn't it?  The answer I've received to this
question is that EOF isn't a request entity delimiter in HTTP/1.1 because
in HTTP/1.1 connections are persistent (by default).

>> Note that the above applies to the socket API.  There may be a
>> completely different algorithm for determining when the
>> connection is closed when using other API, particularly event-
>> based ones.
>
>Could you elaborate on this? It seems to imply that we might
>have client and server HTTP over TCP implementations, one built
>on the socket API, one built on something else, each with
>different mappings of TCP behaviour to HTTP behaviour, hence that
>the two might not be fully interoperable. I'm not sufficiently
>familiar with non-socket APIs to say whether this would be likely
>to be a problem in practice, but it certainly seems like a
>worrying prospect.
>

There is a popular API can't do half-closes:  Java.  At least until
recently, a close() in Java closes both sides of the connection (even if
only applied to the InputStream or OutputStream obtained from the Socket).

>> The reason this isn't defined in the HTTP spec is because it is
>> not an interoperability issue for the application protocol --
>> it is an implementation detail that is entirely dependent on
>> the nature of the lower-layer API used by the application.  It
>> is the stuff for a good book on network programming.
>
>Perhaps it's not an issue for the abstract protocol, but it is
>an issue for it's most common concrete realization. Isn't this
>sort of interaction between the transport layer and the
>application layer precisely the sort of thing which prompted
>Jim Gettys and Alan Freiers "HTTP Connection Management" ID?
>
>On the face of it, it'd be useful to have one or more transport
>layer specific profiles as adjuncts to the abstract protocol
>specification.
>
>Cheers,
>
>
>Miles
>
>--
>Miles Sabin                               InterX
>Internet Systems Architect                5/6 Glenthorne Mews
>+44 (0)20 8817 4030                       London, W6 0LJ, England
>msabin@interx.com                         http://www.interx.com/
>

     -Carl



From 2kseema@sun20.datamatics.com Fri Mar 30 03:58:46 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa24542 ; 30 Mar 2001 03:58 PST
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa06671 ; 30 Mar 2001 03:58 PST
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id MAA17110;
	Fri, 30 Mar 2001 12:56:57 +0100 (BST)
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id MAA24672; Fri, 30 Mar 2001 12:56:46 +0100 (BST)
Resent-Date: Fri, 30 Mar 2001 12:56:46 +0100 (BST)
Message-ID: <002201c0b90e$51ead8c0$524111cf@datamatics.com>
From: Seema P Kumar <2kseema@sun20.datamatics.com>
To: http-wg@cuckoo.hpl.hp.com
MMDF-Warning:  Parse error in original version of preceding line at poindexter-relay.ics.uci.edu
Subject: Problem with multipart/x-mixed replace
Date: Fri, 30 Mar 2001 17:11:10 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001F_01C0B93C.6AB81880"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Resent-Message-ID: <"KxAAy2.0.k06.aG7nw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1039
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

This is a multi-part message in MIME format.

------=_NextPart_000_001F_01C0B93C.6AB81880
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all !

 Could anybody tell me about the "multipart/x-mixed-replace" content =
type ?
 I try to use thie content type for my HTTPServletResponse object in my =
Java servlet, to keep
 outputting messages to
 the browser, but however, the browser does not interpret the headers
 properly and all the tags are visible as
 part of the browser content (I use Internet Explorer 5.0).

The following is the Java code :
public class RefreshingServlet extends HttpServlet{
=20
=20
 public void init(ServletConfig config) throws ServletException{
  super.init(config);
       =20
 }

public void service(HttpServletRequest req, HttpServletResponse res)
    throws ServletException, IOException
{
    =
res.setContentType("multipart/x-mixed-replace;boundary=3D\"boundary\"");
   =20
  PrintWriter out=3Dres.getWriter();
    // Here is the first part
    out.print("\n\r--boundary\n\r");
    out.print("Content-Type: text/html\n\r");

    out.println("<H1>Waiting...</H1>");
    out.flush();

    // Here is the long work (here, a sleep)
    try {
         Thread.sleep(3000);
    }
    catch (Exception e) {
         // ignore
    }

    // Here is the second part
    out.print("\n\r--boundary\n\r");
    out.print("Content-Type: text/html\n\r");

    out.println("<H1>Done</H1>");

    out.print("\n\r--boundary--\n\r");
    out.flush();
}

}

Any loopholes for this ?

Regards,
Seema Kumar
Datamatics Technologies Ltd.,
(Tel: 8290829 (Ext:619))

------=_NextPart_000_001F_01C0B93C.6AB81880
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi all !</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;Could anybody tell me about the=20
"multipart/x-mixed-replace" content type ?<BR>&nbsp;I try to use thie =
content=20
type for my HTTPServletResponse object in my Java servlet, to=20
keep<BR>&nbsp;outputting messages to<BR>&nbsp;the browser, but however, =
the=20
browser does not interpret the headers<BR>&nbsp;properly and all the =
tags are=20
visible as<BR>&nbsp;part of the browser content (I use Internet Explorer =

5.0).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The following is the Java code =
:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>public class RefreshingServlet extends=20
HttpServlet{<BR>&nbsp;<BR>&nbsp;<BR>&nbsp;public void init(ServletConfig =
config)=20
throws=20
ServletException{<BR>&nbsp;&nbsp;super.init(config);<BR>&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;}</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>public void service(HttpServletRequest =
req,=20
HttpServletResponse res)<BR>&nbsp;&nbsp;&nbsp; throws ServletException,=20
IOException<BR>{<BR>&nbsp;&nbsp;&nbsp;=20
res.setContentType("multipart/x-mixed-replace;boundary=3D\"boundary\"");<=
BR>&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;PrintWriter out=3Dres.getWriter();<BR>&nbsp;&nbsp;&nbsp; =
// Here=20
is the first part<BR>&nbsp;&nbsp;&nbsp;=20
out.print("\n\r--boundary\n\r");<BR>&nbsp;&nbsp;&nbsp; =
out.print("Content-Type:=20
text/html\n\r");</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;=20
out.println("&lt;H1&gt;Waiting...&lt;/H1&gt;");<BR>&nbsp;&nbsp;&nbsp;=20
out.flush();</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; // Here is the long =
work (here,=20
a sleep)<BR>&nbsp;&nbsp;&nbsp; try=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Thread.sleep(3000);<BR>&nbsp;&nbsp;&nbsp; }<BR>&nbsp;&nbsp;&nbsp; catch=20
(Exception e) {<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //=20
ignore<BR>&nbsp;&nbsp;&nbsp; }</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; // Here is the =
second=20
part<BR>&nbsp;&nbsp;&nbsp;=20
out.print("\n\r--boundary\n\r");<BR>&nbsp;&nbsp;&nbsp; =
out.print("Content-Type:=20
text/html\n\r");</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;=20
out.println("&lt;H1&gt;Done&lt;/H1&gt;");</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;=20
out.print("\n\r--boundary--\n\r");<BR>&nbsp;&nbsp;&nbsp;=20
out.flush();<BR>}</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>}<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Any loopholes for this =
?<BR></DIV></FONT>
<DIV><FONT face=3DArial size=3D2>Regards,<BR>Seema Kumar<BR>Datamatics =
Technologies=20
Ltd.,<BR>(Tel: 8290829 (Ext:619))</FONT></DIV></BODY></HTML>

------=_NextPart_000_001F_01C0B93C.6AB81880--


From kugler@us.ibm.com Fri Apr  6 13:57:35 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa22012 for <hyper>;
          6 Apr 2001 13:57 PDT
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa00377
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 6 Apr 2001 13:57 PDT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id VAA06842;
	Fri, 6 Apr 2001 21:55:43 +0100 (BST)
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id VAA02188; Fri, 6 Apr 2001 21:55:26 +0100 (BST)
Resent-Date: Fri, 6 Apr 2001 21:55:26 +0100 (BST)
Subject: Re: Problem with multipart/x-mixed replace
To: Seema P Kumar <2kseema@sun20.datamatics.com>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: <OF982B43A7.2C05AEEA-ON87256A26.0071BA66@LocalDomain>
From: Carl Kugler <kugler@us.ibm.com>
Date: Fri, 6 Apr 2001 14:51:44 -0600
X-MIMETrack: Serialize by Router on D03NM103/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 04/06/2001 02:51:45 PM
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
Resent-Message-ID: <"diHl7.0.vX.uoYpw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1040
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


I think you will find that IE does not support  "multipart/x-mixed-repl=
ace"
despite its claim of "User-Agent:=A0 Mozilla/4.0 (compatible..."

You might try asking over on www-talk (see
http://lists.w3.org/Archives/Public/www-talk/).

     -Carl



                                                                       =
                                            =20
                    "Seema P Kumar"                                    =
                                            =20
                    <2kseema@sun20.datam       To:     <http-wg@cuckoo.=
hpl.hp.com>                                 =20
                    atics.com>                 cc:                     =
                                            =20
                                               Subject:     Problem wit=
h multipart/x-mixed replace                 =20
                    03/30/2001 04:41 AM                                =
                                            =20
                                                                       =
                                            =20
                                                                       =
                                            =20





Hi all !

=A0Could anybody tell me about the  "multipart/x-mixed-replace" content=
 type
?
=A0I try to use thie content  type for my HTTPServletResponse object in=
 my
Java servlet, to  keep
=A0outputting messages to
=A0the browser, but however, the  browser does not interpret the header=
s
=A0properly and all the tags are  visible as
=A0part of the browser content (I use Internet Explorer  5.0).

The following is the Java code :
public class RefreshingServlet extends  HttpServlet{


=A0public void init(ServletConfig config)  throws  ServletException{
=A0=A0super.init(config);

=A0}

public void service(HttpServletRequest req,  HttpServletResponse res)
=A0=A0=A0 throws ServletException,  IOException
{
=A0=A0=A0  res.setContentType("multipart/x-mixed-replace;boundary=3D\"b=
oundary\"");

=A0=A0PrintWriter out=3Dres.getWriter();
=A0=A0=A0 // Here  is the first part
=A0=A0=A0  out.print("\n\r--boundary\n\r");
=A0=A0=A0 out.print("Content-Type:  text/html\n\r");

=A0=A0=A0  out.println("<H1>Waiting...</H1>");
=A0=A0=A0  out.flush();

=A0=A0=A0 // Here is the long work (here,  a sleep)
=A0=A0=A0 try
=A0=A0=A0=A0=A0=A0=A0=A0  Thread.sleep(3000);
=A0=A0=A0 }
=A0=A0=A0 catch  (Exception e) {
=A0=A0=A0=A0=A0=A0=A0=A0 //  ignore
=A0=A0=A0 }

=A0=A0=A0 // Here is the second  part
=A0=A0=A0  out.print("\n\r--boundary\n\r");
=A0=A0=A0 out.print("Content-Type:  text/html\n\r");

=A0=A0=A0  out.println("<H1>Done</H1>");

=A0=A0=A0  out.print("\n\r--boundary--\n\r");
=A0=A0=A0  out.flush();
}

}

Any loopholes for this ?

Regards,
Seema Kumar
Datamatics Technologies  Ltd.,
(Tel: 8290829 (Ext:619))

=



From mogul@pa.dec.com Wed Apr 11 11:52:02 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa28795 for <hyper>;
          11 Apr 2001 11:52 PDT
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa26361
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 11 Apr 2001 11:51 PDT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id TAA27480;
	Wed, 11 Apr 2001 19:50:32 +0100 (BST)
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id TAA29505; Wed, 11 Apr 2001 19:50:13 +0100 (BST)
Resent-Date: Wed, 11 Apr 2001 19:50:13 +0100 (BST)
From: Jeffrey Mogul <mogul@pa.dec.com>
Message-Id: <200104111846.LAA05896@wera.pa.dec.com>
To: http-wg@hplb.hpl.hp.com
Subject: Proposal (I-D) for extending HTTP to support out-of-order responses
Date: Wed, 11 Apr 2001 11:46:02 -0700
X-Mts: smtp
Resent-Message-ID: <"lYWH5.0.gB7.TRArw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1041
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

A few weeks ago, I gave a short "Work In Progress" talk at
USITS (the "USENIX Symposium on Internet Technologies and
Systems") about some very early research results I had obtained
about the potential value of supporting out-of-order responses
in HTTP.

Several people came up to me after the talk and seemed very eager
to try out this kind of mechanism.  One person had even
implemented the idea in his own server code while the session was
in progress.  So it seemed like it might be a good idea to
propose a standard extension *before* lots of people started to
deploy this kind of thing.  Hence, I wrote up a simple proposal
as an Internet-Draft:

	Title		: Support for out-of-order responses in HTTP
	Author(s)	: J. Mogul
	Filename	: draft-mogul-http-ooo-00.txt
	Pages		: 14
	Date		: 09-Apr-01

	http://www.ietf.org/internet-drafts/draft-mogul-http-ooo-00.txt
	
    The introduction of persistent connections and pipelining
    into HTTP has resulted in potential performance benefits,
    but has also exposed the problem of head-of-line blocking.
    A simple, compatible, and optional extension to HTTP to
    allow a server to issue responses out of order could
    significantly reduce HOL blocking.  In this extension,
    clients add short ID fields to their requests, and servers
    echo these IDs back in their responses.  This extension is
    defined as a hop-by-hop rather than end-to-end mechanism,
    so it avoids much of the complexity of the end-to-end
    approach.
    
If members of the HTTP-WG mailing list have comments on this,
I'd be happy to receive them.

I want to stress that the research evaluation that might prove
(or disprove) the value of this approach has NOT been finished.
So it does not make sense to start an argument about whether
this is useful (unless someone else has already done a careful
evaluation of this kind of approach).

I'm just looking for comments on whether the protocol makes sense
(and, in particular, whether it might lead to screwups by caching
proxies that don't comply with the HTTP specifications).

Thanks
-Jeff


From fielding@ebuilt.com Wed Apr 11 17:25:43 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa06653 for <hyper>;
          11 Apr 2001 17:25 PDT
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa29322
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 11 Apr 2001 17:25 PDT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id BAA05531;
	Thu, 12 Apr 2001 01:24:52 +0100 (BST)
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id BAA01159; Thu, 12 Apr 2001 01:24:31 +0100 (BST)
Resent-Date: Thu, 12 Apr 2001 01:24:31 +0100 (BST)
Date: Wed, 11 Apr 2001 17:05:40 -0700
From: "Roy T. Fielding" <fielding@ebuilt.com>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg@hplb.hpl.hp.com
Subject: Re: Proposal (I-D) for extending HTTP to support out-of-order responses
Message-ID: <20010411170540.C912@waka.ebuilt.net>
References: <200104111846.LAA05896@wera.pa.dec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13-current-20010115i
In-Reply-To: <200104111846.LAA05896@wera.pa.dec.com>; from mogul@pa.dec.com on Wed, Apr 11, 2001 at 11:46:02AM -0700
X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/)
Resent-Message-ID: <"KAo7J3.0.bG.wKFrw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1042
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

That is a nice draft -- very complete and readable.  I remember discussing
the out-of-order question with some of the CERN folks in October 1994 at
the Chicago WWW conference.  The conclusion we came to was that it would
be easier to deploy SCP as an incompatible protocol than it would be to fix
all of the pre-standard HTTP/1.0 implementations, with more to gain from
doing the former.  I suspect we are still at that state.

One thing I've toyed with in the past was to use a hierarchical request
ID as a poor man's form of transaction identifier.  That is,

   TID: 1234

would be a simple request #1234, whereas

   TID: 888/1234

would indicate that request 1234 was part of transaction 888, and

   TID: 7/888/1234

would be transaction 7, sub-transaction 888, request 1234.  Naturally,

   TID: http://example.com/7/888/1234

would be the globally unique identifier, if such were needed.  Killing
two birds with one stone.

Cheers,

Roy T. Fielding, Chief Scientist, eBuilt, Inc.
                 2652 McGaw Avenue
                 Irvine, CA 92614-5840  fax:+1.949.609.0001
                 (fielding@ebuilt.com)  <http://www.eBuilt.com>


From mcmanus@appliedtheory.com Thu Apr 12 13:11:49 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa05717 for <hyper>;
          12 Apr 2001 13:11 PDT
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa06402
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 12 Apr 2001 13:11 PDT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id VAA10342;
	Thu, 12 Apr 2001 21:10:03 +0100 (BST)
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id VAA12594; Thu, 12 Apr 2001 21:09:42 +0100 (BST)
Resent-Date: Thu, 12 Apr 2001 21:09:42 +0100 (BST)
Date: Thu, 12 Apr 2001 16:03:22 -0400
From: Patrick McManus <mcmanus@appliedtheory.com>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg@hplb.hpl.hp.com
Subject: Re: Proposal (I-D) for extending HTTP to support out-of-order responses
Message-ID: <20010412160322.A12494@AppliedTheory.com>
Reply-To: mcmanus@appliedtheory.com
References: <200104111846.LAA05896@wera.pa.dec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <200104111846.LAA05896@wera.pa.dec.com>; from mogul@pa.dec.com on Wed, Apr 11, 2001 at 11:46:02AM -0700
Resent-Message-ID: <"4SsSt1.0.t33.-hWrw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1043
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com


> I'm just looking for comments on whether the protocol makes sense
> (and, in particular, whether it might lead to screwups by caching
> proxies that don't comply with the HTTP specifications).

2 thoughts, the first is just a throw-away:

1 - HTTP is stateless. indeed 2616 in its intro describes itself this
    way.. this is a pretty fundamental change, even as an optional
    extension.. so the intro should probably discuss it. that's all.

2 - This isn't a safety/correctness thing, but it seems like its a bit of
  a problem to effective usage..

given: 1] non-safe methods like POST or PUT are more likely  to be
          barrier-requests than GETs
 
       2] POSTs and PUTs can have large request bodies with
       significant upload latencies

       3] large request bodies benefit from the expect/100-continue
       mechanism

       4] real networks often have symmetric up and down capactiy that
       its a big win to leverage by overlapping.

I'm thinking about the expect/continue mechanism and how the execution
of a resource by a big POST or PUT is likely to be a sequence point
(and thus a barrier request). the time spent uploading the data would
do well to be overlapped with any outstanding responses even if it
can't be executed until outstanding requests have been processed.. but
if we mark it a sequence point we can't do that because the server
can't say 100-continue until all of the outstanding requests have been
satisfied.. it'd be nice to be able to separate the out-of-order
properties of the 100 with that of the final response so that a "start
sending" signal could be given OOO but the resource itself not
executed OOO. Obviously this requires some server side buffering, and
if it's not willing to do that it could simply do the 100 in-order.

the obvious way to do this seems to be to associate an attribute with
100-continue.. say ERID that works similarly to RID, but applies only
to the 100 response, not the final one.

hopefully the following case played out 3 ways will help illustrate:

assume we've got a POST(d) that takes 6 units to send, and 5 responses
that take 4(a), 5(b.cgi), 2(c), and 2(d), 3(e) to send. throw in the
kicker that b.cgi takes 5 units of time to calculate its response and
d takes 2 units to process the big post.

first, the we'll do the easy case where d is not a request-barrier.


Time    Upstream			    Downstream
----	---------			    -----------
1        GET /a, RID: 1       
2        GET /b.cgi, RID: 2                 200 - RID : 1 (1/4)
3        GET /c, RID: 3			    200 - RID : 1 (2/4)
4        POST /d, RID:4, Expect:..	    200 - RID : 1 (3/4)
5					    200 - RID : 1 (4/4)
6					    100 - RID : 4 (1/1)
7	POST/d, RID: 4 body (1/6)	    200 - RID : 3 (1/2)
8	POST/d, RID: 4 body (2/6)	    200 - RID : 3 (2/2)
9	POST/d, RID: 4 body (3/6)	    200 - RID : 2 (1/5)
10	POST/d, RID: 4 body (4/6)	    200 - RID : 2 (2/5)
11	POST/d, RID: 4 body (5/6)	    200 - RID : 2 (3/5)
12	POST/d, RID: 4 body (6/6)	    200 - RID : 2 (4/5)
13	GET /e, RID: 5			    200 - RID : 2 (5/5)
14					    200 - RID : 5 (1/3)
15					    200 - RID : 5 (2/3)
16					    200 - RID : 5 (3/3)
17					    200 - RID : 4 (1/2)
18					    200 - RID : 4 (2/2)

18 units.. pretty cool.. 

but now, what if /d (the post) is a request barrier under mogul-00?

Time    Upstream			    Downstream
----	---------			    -----------
1        GET /a, RID: 1       
2        GET /b.cgi, RID: 2                 200 - RID : 1 (1/4)
3        GET /c, RID: 3			    200 - RID : 1 (2/4)
4        POST /d,  Expect:..		    200 - RID : 1 (3/4)
5					    200 - RID : 1 (4/4)
6					    200 - RID : 3 (1/2)
7					    200 - RID : 3 (2/2)
8					    200 - RID : 2 (1/5)
9					    200 - RID : 2 (2/5)
10					    200 - RID : 2 (3/5)
11					    200 - RID : 2 (4/5)
12					    200 - RID : 2 (5/5)
13					    100 continue
14       POST/d, body (1/6)
15       POST/d, body (2/6)
16       POST/d, body (3/6)
17       POST/d, body (4/6)
18       POST/d, body (5/6)
19       POST/d, body (6/6)
20	 GET /e, RID: 5			    [wait - processing d]
21		 			    [wait - processing d]
22					    200   (1/2)	 
23					    200   (2/2)	 
24					    200 - RID : 5 (1/3)
25					    200 - RID : 5 (1/3)
26					    200 - RID : 5 (1/3)

26 units.. not as cool.. but what if the 100-continue could be out of
order, without making the final response out of order?

Time    Upstream			    Downstream
----	---------			    -----------
1        GET /a RID: 1       
2        GET /b.cgi, RID: 2                 200 - RID : 1 (1/4)
3        GET /c, RID: 3			    200 - RID : 1 (2/4)
4        POST /d, Expect: 100-c..; ERID=E1  200 - RID : 1 (3/4)
5					    200 - RID : 1 (4/4)
6					    100 - ERID : E1 (1/1)
7	POST/d, RID: 4 body (1/6)	    200 - RID : 3 (1/2)
8	POST/d, RID: 4 body (2/6)	    200 - RID : 3 (2/2)
9	POST/d, RID: 4 body (3/6)	    200 - RID : 2 (1/5)
10	POST/d, RID: 4 body (4/6)	    200 - RID : 2 (2/5)
11	POST/d, RID: 4 body (5/6)	    200 - RID : 2 (3/5)
12	POST/d, RID: 4 body (6/6)	    200 - RID : 2 (4/5)
13	GET /e, RID: 5			    200 - RID : 2 (5/5)
14					    [ wait - processing d]
15					    200 (1/2)
16					    200 (1/2)
17					    200 - RID : 5 (1/3)
18					    200 - RID : 5 (2/3)
19					    200 - RID : 5 (3/3)

19 units!

-Patrick


From fielding@ebuilt.com Thu Apr 12 14:17:28 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa12823 for <hyper>;
          12 Apr 2001 14:17 PDT
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa18673
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 12 Apr 2001 14:17 PDT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id WAA11834;
	Thu, 12 Apr 2001 22:16:40 +0100 (BST)
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id WAA13555; Thu, 12 Apr 2001 22:16:21 +0100 (BST)
Resent-Date: Thu, 12 Apr 2001 22:16:21 +0100 (BST)
Date: Thu, 12 Apr 2001 13:58:35 -0700
From: "Roy T. Fielding" <fielding@ebuilt.com>
To: Patrick McManus <mcmanus@appliedtheory.com>
Cc: Jeffrey Mogul <mogul@pa.dec.com>, http-wg@hplb.hpl.hp.com
Subject: Re: Proposal (I-D) for extending HTTP to support out-of-order responses
Message-ID: <20010412135835.A1120@waka.ebuilt.net>
References: <200104111846.LAA05896@wera.pa.dec.com> <20010412160322.A12494@AppliedTheory.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13-current-20010115i
In-Reply-To: <20010412160322.A12494@AppliedTheory.com>; from mcmanus@appliedtheory.com on Thu, Apr 12, 2001 at 04:03:22PM -0400
X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/)
Resent-Message-ID: <"e3i4I2.0.OI3.TgXrw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1044
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

> 2 thoughts, the first is just a throw-away:
> 
> 1 - HTTP is stateless. indeed 2616 in its intro describes itself this
>     way.. this is a pretty fundamental change, even as an optional
>     extension.. so the intro should probably discuss it. that's all.

HTTP is stateless in the sense that all of the information needed to
interpret and handle a request is present in that request and not based
on a prior request's leftover state.  A RID doesn't change that in
principle, though it would certainly complicate the implementation
to handle out-of-order responses.  On the server-side, the ability
to have out-of-order responses makes it easier to partition pipelined
requests out to multiple server instances, which is one of the main
reasons why HTTP is stateless.

....Roy


From taha.masood@streaming-networks.com Thu Apr 19 23:46:40 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa26013 for <hyper>;
          19 Apr 2001 23:46 PDT
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa19419
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 19 Apr 2001 23:46 PDT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id HAA25910;
	Fri, 20 Apr 2001 07:45:04 +0100 (BST)
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id HAA10665; Fri, 20 Apr 2001 07:44:44 +0100 (BST)
Resent-Date: Fri, 20 Apr 2001 07:44:44 +0100 (BST)
Message-ID: <003a01c0c9c9$031cc340$2b05a8c0@streamingnetworks.com>
From: Taha Masood <taha.masood@streaming-networks.com>
To: http-wg@hplb.hpl.hp.com
MMDF-Warning:  Parse error in original version of preceding line at poindexter-relay.ics.uci.edu
Subject: Confusion regarding following a link
Date: Fri, 20 Apr 2001 11:37:17 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0031_01C0C98E.40CEAF40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Resent-Message-ID: <"6z8nE2.0.Cb2.Jfztw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1045
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01C0C98E.40CEAF40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi folks ,

I have a little confusion regarding HTTP , I would appreciate if someone =
could help me solve it.
The problem is as follows:

e.g. I give the following request to a browser:
http://directory.google.com/Top/Computers/Algorithms/

it Builds the a request that aprt from other things contains the =
following in which I am interested now:

GET /Top/Computers/Algorithms/ HTTP/1.1
Host: directory.google.com


Fine , the server responds back and gives an HTML page to me back .
Now I render the HTML to my GUI .
The HTML contains the following link:

<a =
href=3D"/Top/Science/Math/Applications/Communication_Theory/Cryptography/=
Algorithms/">Cryptography</a>

Now the confusion is that if  my user "clicks" on the hyperlink given =
above , what request should I generate :

What I used to do till now was to classify the situation into three =
portions:

  Whenever we are currently viewing a certain page on the web , and we =
try=20
  to follow a link to another page , there can be three cases. For all =
the=20
  cases , the current page is say : www.abc.com/help/u1/myHelp.html

  FIRST CASE:
  The link I try to follow is : "/yourHelp.com"
  Effective URL should be:
  www.abc.com/help/u1/yourHelp.com

  SECOND CASE:
  The link I try to follow is : "../../TopLevelHelp.com"
  Effective URL should be:
  www.abc.com/TopLevelHelp.com

  THIRD CASE:
  The link I try to follow is : "www.beta.com/OtherHelp.com"
  Effective URL should be:
  www.beta.com/OtherHelp.com

I had implemented a little parsing in my application which works in a =
way that it is given the URL of the resource currently being displayed =
and the link which we are trying to follow , which given in the HTML =
after " <a href=3D " tag. , and then it returns an Effective URL which =
actually has to be shown . From that URL , I separate the Host part and =
the relative part , and  build an HTTP request and pass it on to the =
server . IT used to work pretty fine till now , but I encountered an =
error today , that led me to believe that I was probably NOT =
understanding the things probably.

The problem occurred when I got to the page :

http://directory.google.com/Top/Computers/Algorithms/

The above contains a line in HTML as :
<a =
href=3D"/Top/Science/Math/Applications/Communication_Theory/Cryptography/=
Algorithms/">Cryptography</a>

Now when  my user "clicks" on the hyperlink given above , according to =
my CASES , this thing falls into the FIRST CASE , and what I do is that =
the EFFECTIVE URL made is:

http://directory.google.com/Top/Computers/Algorithms/Top/Science/Math/App=
lications/Communication_Theory/Cryptography/Algorithms/

Fine , so I remove the host and relative part and Build the HTTP request =
:

GET =
/Top/Computers/Algorithms/Top/Science/Math/Applications/Communication_The=
ory/Cryptography/Algorithms/  HTTP/1.1
Host: directory.google.com

The server replies that this resource is not there .

When I follow  the same link through MS Internet Explorer , the request =
it generates is :

GET =
/Top/Science/Math/Applications/Communication_Theory/Cryptography/Algorith=
ms/ HTTP/1.1
Host: directory.google.com


I fail to understand what are the General Rules for following links ? =
What portion of the RFC refers to it ?

I would really appreciate if someone could explain this to me .

Thanks in advance ,

Regards,
Taha









------=_NextPart_000_0031_01C0C98E.40CEAF40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi folks ,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have a little confusion regarding =
HTTP , I would=20
appreciate if someone could help me solve it.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The problem is as follows:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>e.g. I give the following request to a=20
browser:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://directory.google.com/Top/Computers/Algorithms/">http://dir=
ectory.google.com/Top/Computers/Algorithms/</A></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>it Builds the a request that aprt from =
other things=20
contains the following in which I am interested now:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>GET /Top/Computers/Algorithms/=20
HTTP/1.1</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Host: directory.google.com</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Fine , the server responds back and =
gives an HTML=20
page to me back .</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Now I render the HTML to my GUI =
.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The HTML contains the following =
link:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&lt;a=20
href=3D"/Top/Science/Math/Applications/Communication_Theory/Cryptography/=
Algorithms/"&gt;Cryptography&lt;/a&gt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Now the confusion is that if&nbsp; my =
user "clicks"=20
on the hyperlink given above , what request should I generate =
:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>What I used to do till now was to =
classify the=20
situation into three portions:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; Whenever we are currently =
viewing a certain=20
page on the web , and we try <BR>&nbsp; to follow a link to another page =
, there=20
can be three cases. For all the <BR>&nbsp; cases , the current page is =
say : <A=20
href=3D"http://www.abc.com/help/u1/myHelp.html">www.abc.com/help/u1/myHel=
p.html</A></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; FIRST CASE:<BR>&nbsp; The link I =
try to=20
follow is : "/yourHelp.com"<BR>&nbsp; Effective URL should be:<BR>&nbsp; =
<A=20
href=3D"http://www.abc.com/help/u1/yourHelp.com">www.abc.com/help/u1/your=
Help.com</A></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; SECOND CASE:<BR>&nbsp; The link =
I try to=20
follow is : "../../TopLevelHelp.com"<BR>&nbsp; Effective URL should=20
be:<BR>&nbsp; <A=20
href=3D"http://www.abc.com/TopLevelHelp.com">www.abc.com/TopLevelHelp.com=
</A></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; THIRD CASE:<BR>&nbsp; The link I =
try to=20
follow is : "<A=20
href=3D"http://www.beta.com/OtherHelp.com">www.beta.com/OtherHelp.com</A>=
"<BR>&nbsp;=20
Effective URL should be:<BR>&nbsp; <A=20
href=3D"http://www.beta.com/OtherHelp.com">www.beta.com/OtherHelp.com</A>=
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I had implemented a little parsing in =
my=20
application which works in a way that it is given the URL of the =
resource=20
currently being displayed and the link which we are trying to follow , =
which=20
given in the HTML after " &lt;a href=3D " tag. , and then it returns an =
Effective=20
URL which actually has to be shown . From that URL , I separate the Host =
part=20
and the relative part , and&nbsp; build an HTTP request and pass it on =
to the=20
server . IT used to work pretty fine till now , but I encountered an =
error today=20
, that led me to believe that I was probably NOT understanding the =
things=20
probably.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The problem occurred when I got to the =
page=20
:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2><A=20
href=3D"http://directory.google.com/Top/Computers/Algorithms/">http://dir=
ectory.google.com/Top/Computers/Algorithms/</A></FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The above contains a line in HTML as =
:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>&lt;a=20
href=3D"/Top/Science/Math/Applications/Communication_Theory/Cryptography/=
Algorithms/"&gt;Cryptography&lt;/a&gt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Now&nbsp;when  my user "clicks" on the =
hyperlink=20
given above , according to my CASES , this thing falls into the FIRST =
CASE , and=20
what I do is that the EFFECTIVE URL made is:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><A=20
href=3D"http://directory.google.com/Top/Computers/Algorithms/Top/Science/=
Math/Applications/Communication_Theory/Cryptography/Algorithms/">http://d=
irectory.google.com/Top/Computers/Algorithms/Top/Science/Math/Application=
s/Communication_Theory/Cryptography/Algorithms/</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>Fine , so I remove the host and relative part and Build the HTTP =
request=20
:</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>GET=20
/Top/Computers/Algorithms/Top/Science/Math/Applications/Communication_The=
ory/Cryptography/Algorithms/=20
 HTTP/1.1</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Host: directory.google.com</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>The server replies that this resource is not there .</DIV>
<DIV>&nbsp;</DIV>
<DIV>When I follow&nbsp; the same link through MS Internet Explorer , =
the=20
request it generates is :</DIV>
<DIV>&nbsp;</DIV>
<DIV>GET=20
/Top/Science/Math/Applications/Communication_Theory/Cryptography/Algorith=
ms/=20
HTTP/1.1</DIV>
<DIV>Host: directory.google.com</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>I fail to understand what are the General Rules for following links =
? What=20
portion of the RFC refers to it ?</DIV>
<DIV>&nbsp;</DIV>
<DIV>I would really appreciate if someone could explain this to me =
.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks in advance ,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>Taha</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></DIV>
<DIV>&nbsp;</DIV></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0031_01C0C98E.40CEAF40--


From derhoermi@gmx.net Fri Apr 20 00:30:55 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa29505 for <hyper>;
          20 Apr 2001 00:30 PDT
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa29072
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 20 Apr 2001 00:30 PDT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id IAA26968;
	Fri, 20 Apr 2001 08:30:08 +0100 (BST)
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id IAA11726; Fri, 20 Apr 2001 08:29:47 +0100 (BST)
Resent-Date: Fri, 20 Apr 2001 08:29:47 +0100 (BST)
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Taha Masood <taha.masood@streaming-networks.com>
Cc: http-wg@hplb.hpl.hp.com
MMDF-Warning:  Parse error in original version of preceding line at poindexter-relay.ics.uci.edu
Subject: Re: Confusion regarding following a link
Date: Fri, 20 Apr 2001 09:27:23 +0200
Organization: Web Programming and IT Development Guru [tm]
Reply-To: Bjoern Hoehrmann <derhoermi@gmx.net>
Message-ID: <vdovdt86rm7477bnbsq8aag9cfjfgqasve@4ax.com>
References: <003a01c0c9c9$031cc340$2b05a8c0@streamingnetworks.com>
In-Reply-To: <003a01c0c9c9$031cc340$2b05a8c0@streamingnetworks.com>
X-Mailer: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Resent-Message-ID: <"3wYkS1.0.tr2.YJ-tw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1046
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by hplb.hpl.hp.com id IAA26968

* Taha Masood wrote:
>e.g. I give the following request to a browser:
>http://directory.google.com/Top/Computers/Algorithms/

>Now I render the HTML to my GUI .
>The HTML contains the following link:
>
><a href=3D"/Top/Science/Math/Applications/Communication_Theory/Cryptogra=
phy/Algorithms/">Cryptography</a>
>
>Now the confusion is that if  my user "clicks" on the
>hyperlink given above , what request should I generate:

Depends on the value of the href attribute of the base element in the
head element :-)

Request URIs must be absolute, either

/Top/Science/Math/Applications/Communication_Theory/Cryptography/Algorith=
ms/

or

http://directory.google.com/Top/Science/Math/Applications/Communication_T=
heory/Cryptography/Algorithms/

or some non-canonical forms of that URI.

>What I used to do till now was to classify the situation into three port=
ions:
>
>  Whenever we are currently viewing a certain page on the web , and we t=
ry=20
>  to follow a link to another page , there can be three cases. For all t=
he=20
>  cases , the current page is say : www.abc.com/help/u1/myHelp.html

Let's say it's http://www.abc.com/help/u1/myHelp.html

>  FIRST CASE:
>  The link I try to follow is : "/yourHelp.com"
>  Effective URL should be:
>  www.abc.com/help/u1/yourHelp.com

http://www.abc.com/yourHelp.com

>  SECOND CASE:
>  The link I try to follow is : "../../TopLevelHelp.com"
>  Effective URL should be:
>  www.abc.com/TopLevelHelp.com

http://www.abc.com/yourHelp.com

>  THIRD CASE:
>  The link I try to follow is : "www.beta.com/OtherHelp.com"
>  Effective URL should be:
>  www.beta.com/OtherHelp.com

http://www.abc.com/www.beta.com/OtherHelp.com

Please read RFC 2396.

>The problem occurred when I got to the page :
>
>http://directory.google.com/Top/Computers/Algorithms/
>
>The above contains a line in HTML as :
><a href=3D"/Top/Science/Math/Applications/Communication_Theory/Cryptogra=
phy/Algorithms/">Cryptography</a>
>
>Now when  my user "clicks" on the hyperlink given above,
>according to my CASES , this thing falls into the FIRST CASE,
>and what I do is that the EFFECTIVE URL made is:
>
>http://directory.google.com/Top/Computers/Algorithms/Top/Science/Math/Ap=
plications/Communication_Theory/Cryptography/Algorithms/

Nope,
http://directory.google.com/Top/Science/Math/Applications/Communication_T=
heory/Cryptography/Algorithms/

>I fail to understand what are the General Rules for following links ? Wh=
at portion of the RFC refers to it ?
>
>I would really appreciate if someone could explain this to me .

Read RFC 2396. If the relative URI (href=3D'...') is an absolute path
href=3D'/...' it completly replaces the old path. RFC 2396 has a lot of
examples on that.

This is no HTTP issue, www-uri@w3.org deals with URIs.

PS: __Please__ wrap your lines after 68 <=3D x <=3D 80 characters.
--=20
Bj=F6rn H=F6hrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld=
.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dageb=FCll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote=
/


From taha.masood@streaming-networks.com Fri Apr 20 00:53:05 2001
Received: from poindexter.ics.uci.edu
           ( poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa01050 for <hyper>;
          20 Apr 2001 00:53 PDT
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa03903
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 20 Apr 2001 00:52 PDT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id IAA27527;
	Fri, 20 Apr 2001 08:52:18 +0100 (BST)
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id IAA12762; Fri, 20 Apr 2001 08:51:59 +0100 (BST)
Resent-Date: Fri, 20 Apr 2001 08:51:59 +0100 (BST)
Message-ID: <008801c0c9d2$6b331980$2b05a8c0@streamingnetworks.com>
From: Taha Masood <taha.masood@streaming-networks.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: http-wg@hplb.hpl.hp.com
MMDF-Warning:  Parse error in original version of preceding line at poindexter-relay.ics.uci.edu
References: <003a01c0c9c9$031cc340$2b05a8c0@streamingnetworks.com> <vdovdt86rm7477bnbsq8aag9cfjfgqasve@4ax.com>
Subject: Re: Confusion regarding following a link
Date: Fri, 20 Apr 2001 12:45:13 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Resent-Message-ID: <"qf42w.0.W53.Le-tw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1047
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by hplb.hpl.hp.com id IAA27527

Thanks a lot

Regards,
Taha
----- Original Message -----
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Taha Masood <taha.masood@streaming-networks.com>
Cc: <http-wg@hplb.hpl.hp.com>
Sent: Friday, April 20, 2001 12:27 AM
Subject: Re: Confusion regarding following a link


> * Taha Masood wrote:
> >e.g. I give the following request to a browser:
> >http://directory.google.com/Top/Computers/Algorithms/
>
> >Now I render the HTML to my GUI .
> >The HTML contains the following link:
> >
> ><a
href=3D"/Top/Science/Math/Applications/Communication_Theory/Cryptography/=
Algor
ithms/">Cryptography</a>
> >
> >Now the confusion is that if  my user "clicks" on the
> >hyperlink given above , what request should I generate:
>
> Depends on the value of the href attribute of the base element in the
> head element :-)
>
> Request URIs must be absolute, either
>
>
/Top/Science/Math/Applications/Communication_Theory/Cryptography/Algorith=
ms/
>
> or
>
>
http://directory.google.com/Top/Science/Math/Applications/Communication_T=
heo
ry/Cryptography/Algorithms/
>
> or some non-canonical forms of that URI.
>
> >What I used to do till now was to classify the situation into three
portions:
> >
> >  Whenever we are currently viewing a certain page on the web , and we
try
> >  to follow a link to another page , there can be three cases. For all
the
> >  cases , the current page is say : www.abc.com/help/u1/myHelp.html
>
> Let's say it's http://www.abc.com/help/u1/myHelp.html
>
> >  FIRST CASE:
> >  The link I try to follow is : "/yourHelp.com"
> >  Effective URL should be:
> >  www.abc.com/help/u1/yourHelp.com
>
> http://www.abc.com/yourHelp.com
>
> >  SECOND CASE:
> >  The link I try to follow is : "../../TopLevelHelp.com"
> >  Effective URL should be:
> >  www.abc.com/TopLevelHelp.com
>
> http://www.abc.com/yourHelp.com
>
> >  THIRD CASE:
> >  The link I try to follow is : "www.beta.com/OtherHelp.com"
> >  Effective URL should be:
> >  www.beta.com/OtherHelp.com
>
> http://www.abc.com/www.beta.com/OtherHelp.com
>
> Please read RFC 2396.
>
> >The problem occurred when I got to the page :
> >
> >http://directory.google.com/Top/Computers/Algorithms/
> >
> >The above contains a line in HTML as :
> ><a
href=3D"/Top/Science/Math/Applications/Communication_Theory/Cryptography/=
Algor
ithms/">Cryptography</a>
> >
> >Now when  my user "clicks" on the hyperlink given above,
> >according to my CASES , this thing falls into the FIRST CASE,
> >and what I do is that the EFFECTIVE URL made is:
> >
>
>http://directory.google.com/Top/Computers/Algorithms/Top/Science/Math/Ap=
pli
cations/Communication_Theory/Cryptography/Algorithms/
>
> Nope,
>
http://directory.google.com/Top/Science/Math/Applications/Communication_T=
heo
ry/Cryptography/Algorithms/
>
> >I fail to understand what are the General Rules for following links ?
What portion of the RFC refers to it ?
> >
> >I would really appreciate if someone could explain this to me .
>
> Read RFC 2396. If the relative URI (href=3D'...') is an absolute path
> href=3D'/...' it completly replaces the old path. RFC 2396 has a lot of
> examples on that.
>
> This is no HTTP issue, www-uri@w3.org deals with URIs.
>
> PS: __Please__ wrap your lines after 68 <=3D x <=3D 80 characters.
> --
> Bj=F6rn H=F6hrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernswor=
ld.de
> am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.d=
e
> 25899 Dageb=FCll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quo=
te/
>


From francis@ecal.com Fri Apr 20 07:00:10 2001
Received: from poindexter.ics.uci.edu
           ( mmdf@poindexter.ics.uci.edu [128.195.1.71] )
          by gremlin-relay.ics.uci.edu id aa23010 for <hyper>;
          20 Apr 2001 07:00 PDT
Received: from hplb.hpl.hp.com  ( hplb.hpl.hp.com [192.6.10.2] )
          by poindexter-relay.ics.uci.edu id aa24721
          for <hyper@gremlin-relay.ICS.UCI.EDU>; 20 Apr 2001 06:59 PDT
Received: from cuckoo.hpl.hp.com (cuckoo.hpl.hp.com [15.144.30.127])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id OAA09935;
	Fri, 20 Apr 2001 14:59:03 +0100 (BST)
Received: (from procmail@localhost) by cuckoo.hpl.hp.com (8.7.6/8.7.3 TIS 5.0) id OAA14191; Fri, 20 Apr 2001 14:58:42 +0100 (BST)
Resent-Date: Fri, 20 Apr 2001 14:58:42 +0100 (BST)
Sender: francis@localhost.localdomain
Message-ID: <3AE04181.DDC6C3FC@ecal.com>
Date: Fri, 20 Apr 2001 10:02:41 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586)
X-Accept-Language: en, de, es
MIME-Version: 1.0
To: http-wg@hplb.hpl.hp.com
Subject: Re: Confusion regarding following a link
References: <003a01c0c9c9$031cc340$2b05a8c0@streamingnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"9jcps1.0.oR3.804uw"@cuckoo>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1048
X-Loop: http-wg@cuckoo.hpl.hp.com
Precedence: list
Resent-Sender: http-wg-request@cuckoo.hpl.hp.com

Taha Masood wrote:

> Now the confusion is that if  my user "clicks" on the hyperlink
> given above , what request should I generate

See RFC-2396, section 5.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Do not suspect that I am not human.          |
|francis@ecal.com|                                             |
\==============================================================/

From jcma@ai.mit.edu  Sun Apr 22 21:07:13 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id VAA07549 for <http-wg@cuckoo.hpl.hp.com>; Sun, 22 Apr 2001 21:07:13 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id VAA12151
	for <http-wg@hplb.hpl.hp.com>; Sun, 22 Apr 2001 21:07:12 +0100 (BST)
Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id VAA02175
	for <http-wg@hplb.hpl.hp.com>; Sun, 22 Apr 2001 21:07:15 +0100 (BST)
Received: (from jcma@localhost)
	by life.ai.mit.edu (8.9.3/8.9.3/AI2.13/ai.master.life:2.21) id QAA01775;
	Sun, 22 Apr 2001 16:03:25 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p04320402b708e889f520@[128.52.39.204]>
Date: Sun, 22 Apr 2001 16:03:21 -0400
To: http-wg@hplb.hpl.hp.com
From: "John C. Mallery" <jcma@ai.mit.edu>
Subject: Server Push: Multipart/X-Mixed-Replace
Content-Type: text/plain; charset="us-ascii"

Does anybody know the current status of this feature from netscape browsers
prior to 6?

This is a useful feature and perhaps there should be an RFC documenting it
so that it is preserved in mainstream browsers.

One useful application would be incremental redisplay, whereby the diffs
are sent during the refresh.  This goes beyond the netscape spec, but this
facility could do it.  For example, one could provide element IDs that should be
updated with the new data.

From dillon@hns.com  Thu Apr 26 16:07:14 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id QAA25583 for <http-wg@cuckoo.hpl.hp.com>; Thu, 26 Apr 2001 16:07:13 +0100 (BST)
From: dillon@hns.com
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA27682
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 26 Apr 2001 16:07:13 +0100 (BST)
Received: from hnssysb.hns.com (hnssysb.hns.com [139.85.52.101])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id QAA17147
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 26 Apr 2001 16:07:11 +0100 (BST)
Received: from ngw2.hns.com (ngw2-179.hns.com [139.85.179.41])
	by hnssysb.hns.com (8.9.0/8.8.7) with SMTP id LAA05051
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 26 Apr 2001 11:03:06 -0400 (EDT)
Received: by ngw2.hns.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 85256A3A.0052E319 ; Thu, 26 Apr 2001 11:05:20 -0400
X-Lotus-FromDomain: HNS
Sender: dillon@hns.com
To: http-wg@cuckoo.hpl.hp.com
Message-ID: <85256A3A.0052E207.00@ngw2.hns.com>
Date: Thu, 26 Apr 2001 11:03:10 -0400
Subject: Seems like the HTTP working group is shut down...
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline




     is that right?

     Doug......................


From dmk@bell-labs.com  Thu Apr 26 18:01:49 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id SAA26939 for <http-wg@cuckoo.hpl.hp.com>; Thu, 26 Apr 2001 18:01:48 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA02878
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 26 Apr 2001 18:01:40 +0100 (BST)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with SMTP id SAA21740
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 26 Apr 2001 18:01:42 +0100 (BST)
Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Thu Apr 26 12:56:58 EDT 2001
Received: from starling.research.bell-labs.com ([135.104.26.187]) by scummy; Thu Apr 26 12:59:24 EDT 2001
Received: from bell-labs.com (aleatory.research.bell-labs.com [135.104.46.50])
	by starling.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id MAA12039;
	Thu, 26 Apr 2001 12:59:12 -0400 (EDT)
Sender: dmk@research.bell-labs.com
Message-ID: <3AE853E0.227D1B3@bell-labs.com>
Date: Thu, 26 Apr 2001 12:59:12 -0400
From: Dave Kristol <dmk@bell-labs.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: dillon@hns.com
CC: http-wg@cuckoo.hpl.hp.com
Subject: Re: Seems like the HTTP working group is shut down...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

dillon@hns.com wrote:

>      is that right?

The HTTP WG within IETF has shut down, yes.

Dave Kristol

From dillon@hns.com  Fri Apr 27 14:26:43 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id OAA09089 for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 14:26:42 +0100 (BST)
From: dillon@hns.com
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id OAA23297
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 14:26:42 +0100 (BST)
Received: from hnssysb.hns.com (hnssysb.hns.com [139.85.52.101])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id OAA20501
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 14:26:45 +0100 (BST)
Received: from ngw2.hns.com (ngw2-179.hns.com [139.85.179.41])
	by hnssysb.hns.com (8.9.0/8.8.7) with SMTP id JAA11201
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 09:22:31 -0400 (EDT)
Received: by ngw2.hns.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 85256A3B.0049AF01 ; Fri, 27 Apr 2001 09:24:49 -0400
X-Lotus-FromDomain: HNS
Sender: dillon@hns.com
To: http-wg@cuckoo.hpl.hp.com
Message-ID: <85256A3B.0049AD9F.00@ngw2.hns.com>
Date: Fri, 27 Apr 2001 09:22:37 -0400
Subject: Whatever happenned to HTTP 1.1 Pipelining
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline




     Seems like a feature which would really help
web-page response time using less resources than multiple
simultaneous connections, but it seems to have never been
adopted.

     I know of no browser that supports it.

     What are the "GOTCHAs" that keep it from being adopted?

     The biggest one that comes to mind is fact that one
of the responses in the pipeline may not have a content-length.
What could be done about that?

     Doug.......................


From kugler@us.ibm.com  Fri Apr 27 15:24:14 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id PAA11481 for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 15:24:14 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id PAA26058
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 15:24:13 +0100 (BST)
Received: from e34.bld.us.ibm.com (e34.co.us.ibm.com [32.97.110.132])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id PAA22917
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 15:24:16 +0100 (BST)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA67878;
	Fri, 27 Apr 2001 10:05:32 -0400
Received: from f6n95e (d03nm103h.boulder.ibm.com [9.99.140.95])
	by westrelay02.boulder.ibm.com (8.8.8m3/NCO v4.96.1.0) with ESMTP id IAA29776;
	Fri, 27 Apr 2001 08:22:43 -0600
Subject: Re: Whatever happenned to HTTP 1.1 Pipelining
To: dillon@hns.com
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: <OF3C52B5D6.A63A1537-ON87256A3B.004EEE5B@LocalDomain>
From: "Carl Kugler" <kugler@us.ibm.com>
Date: Fri, 27 Apr 2001 08:22:42 -0600
X-MIMETrack: Serialize by Router on D03NM103/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 04/27/2001 08:22:43 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii


>     The biggest one that comes to mind is fact that one
> of the responses in the pipeline may not have a content-length.
> What could be done about that?

Use Transfer-Encoding: chunked.

     -Carl

From WilliamW@InterWorld.com  Fri Apr 27 14:34:02 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id OAA09789 for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 14:34:01 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id OAA23648
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 14:34:00 +0100 (BST)
Received: from iwexchange1.interworld.com (emma.interworld.com [38.151.180.5])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id OAA20987
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 14:34:00 +0100 (BST)
Received: by IWEXCHANGE1 with Internet Mail Service (5.5.2653.19)
	id <JW6PD94A>; Fri, 27 Apr 2001 09:32:34 -0400
Message-ID: <F500BDA6D2EAD311AD5B00508BCF2DF3019DA20C@IWEXCHANGE1>
From: "Wallace, William" <WilliamW@InterWorld.com>
To: "'dillon@hns.com'" <dillon@hns.com>, http-wg@cuckoo.hpl.hp.com
Subject: RE: Whatever happenned to HTTP 1.1 Pipelining
Date: Fri, 27 Apr 2001 09:32:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"

The latest version of Opera uses pipelining.

> -----Original Message-----
> From: dillon@hns.com [mailto:dillon@hns.com]
> Sent: Friday, April 27, 2001 9:23 AM
> To: http-wg@cuckoo.hpl.hp.com
> Subject: Whatever happenned to HTTP 1.1 Pipelining
> 
> 
> 
> 
> 
>      Seems like a feature which would really help
> web-page response time using less resources than multiple
> simultaneous connections, but it seems to have never been
> adopted.
> 
>      I know of no browser that supports it.
> 
>      What are the "GOTCHAs" that keep it from being adopted?
> 
>      The biggest one that comes to mind is fact that one
> of the responses in the pipeline may not have a content-length.
> What could be done about that?
> 
>      Doug.......................
> 
> 

From marcs@znep.com  Fri Apr 27 18:37:45 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id SAA14280 for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 18:37:45 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA03522
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 18:37:44 +0100 (BST)
Received: from alive.znep.com (root@sense-sea-MegaSub-1-500.oz.net [216.39.145.246])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id SAA29135
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 18:37:47 +0100 (BST)
Received: from localhost (marcs@localhost)
	by alive.znep.com (8.9.3/8.9.1) with ESMTP id KAA13091
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 10:36:22 -0700 (PDT)
	(envelope-from marcs@znep.com)
Date: Fri, 27 Apr 2001 10:36:22 -0700 (PDT)
From: Marc Slemko <marcs@znep.com>
To: http-wg@cuckoo.hpl.hp.com
Subject: Re: Whatever happenned to HTTP 1.1 Pipelining
In-Reply-To: <85256A3B.005F9E64.00@ngw2.hns.com>
Message-ID: <Pine.BSF.4.20.0104271034120.20876-100000@alive.znep.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 27 Apr 2001 dillon@hns.com wrote:

>      Thankyou for digging that up, but does it
> mean that by a server SHOULD or MUST use self-defined message
> lengths? This doesn't seem to give the browser author any assurance
> that his pipelined requests won't be aborted by a premature connection
> close due to a no CONTENT-LENGTH response.

Then they have to resend the requsts to which they have not received 
responses.  This is why only idempotent requests can be pipelined.

> 
>      Seems to me that you only pipeline after you've gotton one
> request through a connection because you don't know whether the
> other end supports persistent connections. After that first request, which
> handles the negotiation, you'd like to be able to pipeline with worry about the
> pipeline being
> cut off.

You always have to worry about the possibility that the pipeline is cut
off.

From dillon@hns.com  Fri Apr 27 18:26:08 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id SAA13325 for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 18:26:07 +0100 (BST)
From: dillon@hns.com
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA03112
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 18:26:06 +0100 (BST)
Received: from hnssysb.hns.com (hnssysb.hns.com [139.85.52.101])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id SAA28733
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 18:26:09 +0100 (BST)
Received: from ngw2.hns.com (ngw2-179.hns.com [139.85.179.41])
	by hnssysb.hns.com (8.9.0/8.8.7) with SMTP id NAA14964;
	Fri, 27 Apr 2001 13:22:15 -0400 (EDT)
Received: by ngw2.hns.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 85256A3B.005FA030 ; Fri, 27 Apr 2001 13:24:29 -0400
X-Lotus-FromDomain: HNS
Sender: dillon@hns.com
To: "Carl Kugler" <kugler@us.ibm.com>
cc: http-wg@cuckoo.hpl.hp.com
Message-ID: <85256A3B.005F9E64.00@ngw2.hns.com>
Date: Fri, 27 Apr 2001 13:22:16 -0400
Subject: Re: Whatever happenned to HTTP 1.1 Pipelining
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline




     Thankyou for digging that up, but does it
mean that by a server SHOULD or MUST use self-defined message
lengths? This doesn't seem to give the browser author any assurance
that his pipelined requests won't be aborted by a premature connection
close due to a no CONTENT-LENGTH response.

     Seems to me that you only pipeline after you've gotton one
request through a connection because you don't know whether the
other end supports persistent connections. After that first request, which
handles the negotiation, you'd like to be able to pipeline with worry about the
pipeline being
cut off.

     Doug.......................







"Carl Kugler" <kugler@us.ibm.com> on 04/27/2001 11:53:53 AM
                                                                                
                                                                                
                                                                                



                                                              
                                                              
                                                              
 To:      Doug Dillon/HNS@HNS                                 
                                                              
 cc:                                                          
                                                              
                                                              
                                                              
 Subject: Re: Whatever happenned to HTTP 1.1 Pipelining       
                                                              








I found this sentence in section 8.1.2.1, Negotation:

In order to remain persistent, all messages on the connection MUST have a
self-defined message length (i.e., one not defined by closure of the
connection), as described in section 4.4.


     -Carl





                    dillon@hns.com
                                         To:     Carl Kugler/Boulder/IBM@IBMUS
                    04/27/2001           cc:
                    08:36 AM             Subject:     Re: Whatever happenned to
HTTP 1.1
                                          Pipelining









     I naturally thought about that, but is there anything is the RFC
that says that Transfer-Encoding: chunked SHOULD or MUST be used on
persistent
HTTP 1.1 connections instead of sending with no content-length?

     I don't recall seeing that.

     Doug................





"Carl Kugler" <kugler@us.ibm.com> on 04/27/2001 10:22:42 AM









 To:      Doug Dillon/HNS@HNS

 cc:      http-wg@cuckoo.hpl.hp.com



 Subject: Re: Whatever happenned to HTTP 1.1 Pipelining









>     The biggest one that comes to mind is fact that one
> of the responses in the pipeline may not have a content-length.
> What could be done about that?

Use Transfer-Encoding: chunked.

     -Carl

From dillon@hns.com  Mon Apr 30 15:38:02 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id PAA18458 for <http-wg@cuckoo.hpl.hp.com>; Mon, 30 Apr 2001 15:38:01 +0100 (BST)
From: dillon@hns.com
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id PAA25620
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 30 Apr 2001 15:38:00 +0100 (BST)
Received: from hnssysb.hns.com (hnssysb.hns.com [139.85.52.101])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id PAA06947
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 30 Apr 2001 15:38:03 +0100 (BST)
Received: from ngw2.hns.com (ngw2-179.hns.com [139.85.179.41])
	by hnssysb.hns.com (8.9.0/8.8.7) with SMTP id KAA28459
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 30 Apr 2001 10:34:05 -0400 (EDT)
Received: by ngw2.hns.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 85256A3E.00503AE8 ; Mon, 30 Apr 2001 10:36:19 -0400
X-Lotus-FromDomain: HNS
Sender: dillon@hns.com
To: http-wg@cuckoo.hpl.hp.com
Message-ID: <85256A3E.00503A61.00@ngw2.hns.com>
Date: Mon, 30 Apr 2001 10:34:08 -0400
Subject: Low-Response Time Secure Web Browsing
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



     Colleagues,

      I'm interested in having HTTPS provide
low-response time web browsing over long latency
links, such as Satellite. As you know, the extra handshakes
required by TLS tend to increase the response time.

     As such, some colleagues and I have put
together a test bed and are looking at sniffer traces
from various browser/web server combinations to
see whether implementations are using the best
features of HTTP and TLS to achieve low response time.
Initial results indicate that they are not using best
practice.

     I see from the TLS working group that there is
already an informational RFC (2818) regarding the
use of HTTP over TLS, but that this document does not
address performance issues.

     Would anyone on this mailing list be interested
in seeing the results of our testing as they become available?

     Would anyone be interested in reviewing/contributing
to an informational RFC recommending best practice for
low response time?

     Doug.....................


From jcma@ai.mit.edu  Fri Apr 27 21:37:44 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id VAA15830 for <http-wg@cuckoo.hpl.hp.com>; Fri, 27 Apr 2001 21:37:43 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id VAA08654
	for <http-wg@hplb.hpl.hp.com>; Fri, 27 Apr 2001 21:37:43 +0100 (BST)
Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id VAA03064
	for <http-wg@hplb.hpl.hp.com>; Fri, 27 Apr 2001 21:37:46 +0100 (BST)
Received: (from jcma@localhost)
	by life.ai.mit.edu (8.9.3/8.9.3/AI2.13/ai.master.life:2.21) id QAA16073;
	Fri, 27 Apr 2001 16:33:40 -0400 (EDT)
Mime-Version: 1.0
Message-Id: <p04320410b70f69a9d5b7@[128.52.39.204]>
In-Reply-To: <001b01c0ccf5$9b61b6e0$87000096@newtec.com>
References: <p04320402b708e889f520@[128.52.39.204]>
 <001b01c0ccf5$9b61b6e0$87000096@newtec.com>
Date: Fri, 27 Apr 2001 13:25:53 -0500
To: "Miguel Estrada" <mestrada@infograficos.com>
From: "John C. Mallery" <jcma@ai.mit.edu>
Subject: RE: Server Push: Multipart/X-Mixed-Replace
Cc: <http-wg@hplb.hpl.hp.com>
Content-Type: text/plain; charset="us-ascii"

Thanks, but this answer is not related to the question. We already implemented
from the documentation many years ago. Moreover, netscape 6 does not
implement server push (more code base forgetting).

Does anybody know the current status of this feature from netscape browsers
prior to 6?

This is a useful feature and perhaps there should be an RFC documenting it
so that it is preserved in mainstream browsers.

One useful application would be incremental redisplay, whereby the diffs
are sent during the refresh.  This goes beyond the netscape spec, but this
facility could do it.  For example, one could provide element IDs that should be
updated with the new data.


At 21:34 +0200 2001-04-24, Miguel Estrada wrote:
>Hi,
>
>You can find this info in the Netscape web site, bud is not implemented in
>Internet Explorer.
>
>
>Miguel Estrada
>
>
>
>----- Original Message -----
>From: John C. Mallery <jcma@ai.mit.edu>
>To: <http-wg@hplb.hpl.hp.com>
>Sent: Sunday, April 22, 2001 10:03 PM
>Subject: Server Push: Multipart/X-Mixed-Replace
>
>
>> Does anybody know the current status of this feature from netscape
>browsers
>> prior to 6?
>>
>> This is a useful feature and perhaps there should be an RFC documenting it
>> so that it is preserved in mainstream browsers.
>>
>> One useful application would be incremental redisplay, whereby the diffs
>> are sent during the refresh.  This goes beyond the netscape spec, but this
>> facility could do it.  For example, one could provide element IDs that
>should be
>> updated with the new data.
>>
>>
>>
>>

From kugler@us.ibm.com  Mon Apr 30 16:03:27 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id QAA19747 for <http-wg@cuckoo.hpl.hp.com>; Mon, 30 Apr 2001 16:03:27 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA27715
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 30 Apr 2001 16:03:26 +0100 (BST)
Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id QAA08131
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 30 Apr 2001 16:03:28 +0100 (BST)
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23])
	by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA40658;
	Mon, 30 Apr 2001 10:53:02 -0400
Received: from f6n95e (d03nm103h.boulder.ibm.com [9.99.140.95])
	by westrelay02.boulder.ibm.com (8.8.8m3/NCO v4.96.1.0) with ESMTP id JAA29256;
	Mon, 30 Apr 2001 09:00:25 -0600
Subject: Re: Low-Response Time Secure Web Browsing
To: dillon@hns.com
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: <OFF4469CB0.B38C7F6A-ON87256A3E.00526112@LocalDomain>
From: "Carl Kugler" <kugler@us.ibm.com>
Date: Mon, 30 Apr 2001 09:00:36 -0600
X-MIMETrack: Serialize by Router on D03NM103/03/M/IBM(Release 5.0.6 |December 14, 2000) at
 04/30/2001 09:00:24 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii


You find some interest on the HTTP Compliance list at

     http://groups.yahoo.com/group/http-compliance




                                                                                                                   
                    dillon@hns.com                                                                                 
                                         To:     http-wg@cuckoo.hpl.hp.com                                         
                    04/30/2001           cc:                                                                       
                    08:34 AM             Subject:     Low-Response Time Secure Web Browsing                        
                                                                                                                   
                                                                                                                   
                                                                                                                   





     Colleagues,

      I'm interested in having HTTPS provide
low-response time web browsing over long latency
links, such as Satellite. As you know, the extra handshakes
required by TLS tend to increase the response time.

     As such, some colleagues and I have put
together a test bed and are looking at sniffer traces
from various browser/web server combinations to
see whether implementations are using the best
features of HTTP and TLS to achieve low response time.
Initial results indicate that they are not using best
practice.

     I see from the TLS working group that there is
already an informational RFC (2818) regarding the
use of HTTP over TLS, but that this document does not
address performance issues.

     Would anyone on this mailing list be interested
in seeing the results of our testing as they become available?

     Would anyone be interested in reviewing/contributing
to an informational RFC recommending best practice for
low response time?

     Doug.....................






From skgupta@hss.hns.com  Thu May  3 13:01:10 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id NAA02659 for <http-wg@cuckoo.hpl.hp.com>; Thu, 3 May 2001 13:01:09 +0100 (BST)
From: skgupta@hss.hns.com
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id NAA08919
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 3 May 2001 13:01:08 +0100 (BST)
Received: from hindon.hss.co.in ([202.54.26.202])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id NAA28172
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 3 May 2001 13:01:08 +0100 (BST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f43BwMP07058
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 3 May 2001 17:28:23 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A41.004055B6 ; Thu, 3 May 2001 17:12:42 +0530
X-Lotus-FromDomain: HSS
To: http-wg@cuckoo.hpl.hp.com
Message-ID: <65256A41.0040536A.00@sandesh.hss.hns.com>
Date: Thu, 3 May 2001 17:24:34 +0530
Subject: "what does Keep-alive: 300" mean"
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline





I was looking at the header of GET request sent by Mozilla.
I came across this header field "keep-alive: 300".
This field is not present in the GET request sent by
netscape 4.7 and IE 5.0 .


One more doubt, If this field is particular to Mozilla
browser, as my observation suggests, then How the server
is supposed to understand this field ?

------------------------------------------------------------------------------------------------------------
Regards
-Pawan

From francis@ecal.com  Thu May  3 15:47:47 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id PAA04088 for <http-wg@cuckoo.hpl.hp.com>; Thu, 3 May 2001 15:47:45 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id PAA15585
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 3 May 2001 15:47:43 +0100 (BST)
Received: from localhost.localdomain ([216.52.68.3])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id PAA06925
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 3 May 2001 15:47:46 +0100 (BST)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.11.0/8.11.0) with ESMTP id f43EsSt29624
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 3 May 2001 10:54:30 -0400
Sender: francis@localhost.localdomain
Message-ID: <3AF17122.32CCEB21@ecal.com>
Date: Thu, 03 May 2001 10:54:27 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i586)
X-Accept-Language: en, de, es
MIME-Version: 1.0
To: http-wg@cuckoo.hpl.hp.com
Subject: Re: "what does Keep-alive: 300" mean"
References: <65256A41.0040536A.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

skgupta@hss.hns.com wrote:

> One more doubt, If this field is particular to Mozilla
> browser, as my observation suggests, then How the server
> is supposed to understand this field ?

RFC-2068, section 19.7.1

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |I used to belong to a solipsism club, but I got|
|francis@ecal.com|bored & voted everybody else out.              |
\================================================================/

From MSabin@interx.com  Thu May  3 16:19:43 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id QAA05263 for <http-wg@cuckoo.hpl.hp.com>; Thu, 3 May 2001 16:19:43 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA17237
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 3 May 2001 16:19:42 +0100 (BST)
Received: from post0.uk.gts-ebusiness.net (brawne.uk.gts-ebusiness.net [194.42.236.138])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id QAA08383
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 3 May 2001 16:19:46 +0100 (BST)
Received: from [213.235.6.17] (helo=mswwest01.interx.com)
	by post0.uk.gts-ebusiness.net with esmtp (Exim 3.15 #2)
	id 14vKtI-0003lp-00
	for http-wg@cuckoo.hpl.hp.com; Thu, 03 May 2001 16:19:40 +0100
Received: from exwest_01.interx.com (exwest_01.interx.com) by mswwest01.interx.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T534bd843120a000088197@mswwest01.interx.com> for <http-wg@cuckoo.hpl.hp.com>;
 Thu, 3 May 2001 16:19:09 +0100
Received: by exwest_01.interx.com with Internet Mail Service (5.5.2653.19)
	id <KCBPH8ZV>; Thu, 3 May 2001 16:19:09 +0100
Message-ID: <69B15B675E99D411A4110008C786DA230136BB0B@exwest_01.interx.com>
From: Miles Sabin <MSabin@interx.com>
To: http-wg@cuckoo.hpl.hp.com
Subject: RE: "what does Keep-alive: 300" mean"
Date: Thu, 3 May 2001 16:19:06 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"

> > One more doubt, If this field is particular to Mozilla
> > browser, as my observation suggests, then How the server
> > is supposed to understand this field ?
>
> RFC-2068, section 19.7.1

No, it's not that.

The pre-HTTP/1.1 persistent connection mechanism uses,

  Connection: Keep-Alive

on the request side, and on the response side,

  Connection: Keep-Alive

and you might also see the Apache extension,

  Keep-Alive: max=???; timeout=???

Mozilla is the only client I've come across which uses a Keep-Alive:
header on the request side.

Presumably it's a hint to the server that the client will close the
connection after the specified number of seconds. I'm not entirely 
sure what the value of this hint is supposed to be tho'. It might be
useful if the default value were less than 2*MSL, in which case it 
would help a busy server to decide whether leave the client to close 
or take the time wait hit itself. But the default seems to be 300 
secs.

Cheers,


Miles

-- 
Miles Sabin                                     InterX
Internet Systems Architect                      27 Great West Road
+44 (0)20 8817 4030                             Middx, TW8 9AS, UK
msabin@interx.com                               http://www.interx.com/

From hodges@breakaway.Stanford.EDU  Fri May 18 17:05:51 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id RAA00131 for <http-wg@cuckoo.hpl.hp.com>; Fri, 18 May 2001 17:05:49 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id RAA20207
	for <http-wg@hplb.hpl.hp.com>; Fri, 18 May 2001 17:05:48 +0100 (BST)
Received: from breakaway.Stanford.EDU (breakaway.Stanford.EDU [171.64.20.202])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id RAA03210
	for <http-wg@hplb.hpl.hp.com>; Fri, 18 May 2001 17:05:51 +0100 (BST)
Received: from localhost (hodges@localhost)
	by breakaway.Stanford.EDU (8.9.3/8.9.3) with ESMTP id JAA02835;
	Fri, 18 May 2001 09:02:04 -0700 (PDT)
Message-Id: <200105181602.JAA02835@breakaway.Stanford.EDU>
X-Mailer: exmh version 2.0.2 2/24/98
Subject: wrt: Web Protocols and Practice: HTTP/1.1, Networking Protocols, 
 Caching, and Traffic Measurement
To: http-wg@hplb.hpl.hp.com
cc: Jeff.Hodges@kingsmountain.com
From: Jeff.Hodges@kingsmountain.com
Reply-to: Jeff.Hodges@kingsmountain.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 18 May 2001 09:02:03 -0700
Sender: hodges@breakaway.Stanford.EDU

So, have folks on this list reviewed or otherwise seen this book?..

Web Protocols and Practice: HTTP/1.1, Networking Protocols, Caching,
and Traffic Measurement 
 Balachander Krishnamurthy 
 Jennifer Rexford 
 Copyright 2001, 672 pp. 
 ISBN 0-201-71088-9

 http://www.awlonline.com/product/0,2627,0201710889,00.html


[i note Balachander posted to this list back in Oct-2000]


Anyway, it sounds like it is likely a "good book" and worth having, but I'd 
prefer to get some independent confirmation before parting with the $.

To anticipate the question -- yes, given the reprint of the "flap blurbs" on 
the amazon page..

  http://www.amazon.com/exec/obidos/ASIN/0201710889/

..it sounds like it nominally covers the ground I'm interested in knowing more 
about (e.g. Web caching and multimedia streaming, the Apache Web server, Squid 
proxy, and traffic measurement techniques).

thanks,

JeffH

From koen@hep216.cithep.caltech.edu  Tue May  8 08:04:22 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id IAA02210 for <http-wg@cuckoo.hpl.hp.com>; Tue, 8 May 2001 08:04:21 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id IAA06037
	for <http-wg@hplb.hpl.hp.com>; Tue, 8 May 2001 08:04:19 +0100 (BST)
Received: from hep505.cithep.caltech.edu (hep505.cithep.caltech.edu [131.215.126.149])
	by hplb.hpl.hp.com (8.9.3/ HPLabs Bristol Relay) with ESMTP id IAA11869
	for <http-wg@hplb.hpl.hp.com>; Tue, 8 May 2001 08:04:22 +0100 (BST)
Received: from hep216.cithep.caltech.edu (hep216.cithep.caltech.edu [131.215.126.147])
	by hep505.cithep.caltech.edu (8.10.1/8.10.1) with ESMTP id f4872ub06630;
	Tue, 8 May 2001 00:02:57 -0700
Date: Tue, 8 May 2001 00:02:56 -0700 (PDT)
From: Koen Holtman <koen@hep.caltech.edu>
To: Jeffrey Mogul <mogul@pa.dec.com>
cc: http-wg@hplb.hpl.hp.com, Koen Holtman <koen@hep.caltech.edu>
Subject: Re: Proposal (I-D) for extending HTTP to support out-of-order
 responses
In-Reply-To: <200104111846.LAA05896@wera.pa.dec.com>
Message-ID: <Pine.A41.4.10.10105072127280.17796-100000@hep216.cithep.caltech.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Wed, 11 Apr 2001, Jeffrey Mogul wrote:

> 	Title		: Support for out-of-order responses in HTTP
> 	Author(s)	: J. Mogul
> 	Filename	: draft-mogul-http-ooo-00.txt
> 	Pages		: 14
> 	Date		: 09-Apr-01
> 
> 	http://www.ietf.org/internet-drafts/draft-mogul-http-ooo-00.txt

Just read the draft, overall it looks good.  The hop-by-hop approach
seems to be the right one.  I could not discover any potential problems
in interacting with correctly implemented legacy caches.

Some comments:

1. The end of section 3.1 got me thinking a bit:

   A client SHOULD NOT send an RID header field with a request if the
   semantics of the operation might not permit reordering.  A server
   SHOULD NOT reorder a response if the semantics of the operation might
   not permit reordering.  For example, a DELETE request probably ought
   not to be reordered with other requests.

This language is really too vague, as it does not spell out the criteria
for knowing when "the semantics of the operation might not permit
reordering". In theory, as people can layer whatever they want on top of
GET, of course *any* two operations *might* not permit reordering, so what
is a poor proxy in the middle to do?  So what is a hard criterion one can
define for not permitting reordering?

The end of Section 8.1.2.2 (Pipelining) of RFC 2616 gives some guidance
here:

   Clients SHOULD NOT pipeline requests using non-idempotent methods or
   non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
   premature termination of the transport connection could lead to
   indeterminate results. A client wishing to send a non-idempotent
   request SHOULD wait to send that request until it has received the
   response status for the previous request.

So it looks like correctly implemented clients will already avoid
pipelining for non-idempotent requests.  So there will not be a big
potential loss of efficiency if all non-idempotent requests are are
defined as `does not permit reordering'.

On the other hand, 2616 seems to imply that pipelining idempotent requests
is OK.  Also I believe it is considered to be legal for a 1.1 proxy to
multiplex one incoming request stream over multiple outgoing streams to
the same server.  So I believe 1.1 already implies that idempotent
requests could arrive out-of-order at the server -- is this correct?  If
that is the case then just reordering the responses to non-idempotent
requests should also be OK.

So it looks like 2616 implies that the hard criterion for not permitting
re-ordering should be whether the request is non-idempotent.  However the
example in the draft "a DELETE request probably ought not to be reordered
with other requests." seems to even broaden this, as DELETE *is*
idempotent, though not safe.  So this implies a preference for broadening
the criterion to non permitting the re-ordering of unsafe requests???  
Probably so.

One additional observations before I propose new language for the draft..  
In general I do not like the specification style where both sides of the
wire are responsible for enforcing a protocol constraint (here the
constraint is not being able to do response reordering in some cases).
While this style potentially creates a higher tolerance against bugs in
implementations it also adds some software complexity and limits the
ability to override such constraints in protocol extensions.  In this case
I would like the policing of this constraint to be the responsibility of
the client only -- the server should trust that the client knows what it
is doing, as it has potentially out-of-band information about
reorderability.

So all in all I propose this new language to replace the qouted paragraph
above:

   A client MUST NOT send an RID header field on an unsafe
   request (all requests except GET and HEAD requests are unsafe),
   unless it has out-of-band information that the potential
   re-ordering of the response to the request is not a problem.  
   A client MAY send a RID header on any safe request.



2. The language in section 3.1 does not answer these questions:

2A) If a proxy server gets a sequence of (idempotent) requests, all with a
RID header, section 3.1 is currently silent as far as I can see on whether
this means that the requests may be forwarded upstream in a different
order.

2B) If an origin server gets a sequence of (idempotent) requests, all with
a RID header, section 3.1 is currently silent as far as I can see on
whether this means that the requests may be processed (this processing may
generate side effects!!!) in a different order.

Section 2.1 seems to imply that the answers to both these are `yes'.  
According to my reasoning about multiplexing pipelined requests above,
HTTP/1.1 implies that answering `yes' to both 2A) and 2B) should be safe.  
However I am not completely sure if this is true for all HTTP applications
in practice...

In any case, the draft should answer the above questions in the
`specification' section, though I am not sure if the answer to A) should
be yes.

3. The following language at the end of section 3.3 looked scary on first
reading:

   A proxy might need to establish a new inbound transport connection in
   order to allow continued reordering of unrelated responses while
   preserving the ordering constraints implied by the RID-Barrier header
   (relative to a previous request that it has forwarded without yet
   receiving a response).

On second reading I am assuming that "unrelated responses" means
`responses to requests gotten from a different client', which would make
the language non-scary.  Though I am not 100% sure that this is what was
meant, so the language probably needs to be clarified.

4. The purpose of rid-barrier seems to be to separate on the whole path to
the origin server 2 sets of reorderable request sequences for which the
responses should not be mixed among the sequences. HOWEVER if a proxy
somwhere along this path multiplexes the request stream onto 2 (or more)
different outgoing connections (this might easily happen especially if not
all requests are on the same origin server) then one of the streams will
have the rid-barrier missing, which means that the (parts of the) 2
request sequences in this sequence with missing rid-barrier become
re-orderable again. So it looks like rid-barrier will not always work for
its intended use.

Alternatives: 

A1) instead of sending rid-barrier have the client `drain the pipeline'
(as HTTP/1.1 suggests you do before a non-idempotent request), this will
prevent any mixing between the two sequences.

A2) change the RID field to add an extra identifier which denotes a group
of requests with reorderable responses.

i.e.  the sequence (each line a requesr)

RID: 1
RID: 2
RID-BARRIER:
RID: 3
RID: 4

becomes

RID: A,1
RID: A,2
<non-rid normal request, could also be ommitted>
RID: B,3
RID: B,4

and then one can put a constraint on any server that responses can only be
reordered when the first token in the RID field is the same.

I would prefer alternative A1), A2) seems to be overkill.

Note that for the same reason that rid-barrier does not always work, a
nonsafe request between two rid-sequences can also not be counted on to
prevent re-ordering of the responses (and requests too???) between the
sequences further upstream. It looks like to only way to be sure is to
drain the pipeline.  This should be documented in the draft!  If the
answer to question 2A above is `yes' we now have the somewhat non-obvious
result that if the client sends through some proxies

RID: 1
RID: 2
RID-BARRIER or non-safe
RID: 3
RID: 4

without waiting anywhere for the pipeline to drain, it is entirely
possible that the origin server will see

RID: 4
RID: 3
RID-BARRIER or non-safe
RID: 2
RID: 1

because a proxy in the middle multiplexed the `RID-BARRIER or non-safe'
onto a different connection than the other requests.

5. About the security considerations: if a client sends

GET /a RID: 1
GET /b RID: 2

then resource /a could potentially respond with

200 OK
RID: 2
bla bla bla

thus spoofing a reponse from resource /b!!!  Resource /a might then get
the server to abort or hang the connection -- a client or proxy getting
the single response might then cache or use the response as a valid
response from /b without suspecting that anything is wrong. If /b is a
known URL at which to get a certificate this will be a problem...  The
attacker /a might be able to put up a web page that makes many browsers
emit the above two requests with a high predictability. 


In general a client cannot assume that two resources on the other end of a
hop-to-hop connection are in the same trust domain.  Also in the
arrangement

rid-aware client --- 1.1 proxy not rid-aware -- origin server with /a
                                           \
                                            ---- origin server with /b

unless the client has checks to prevent this, the resource /a could spoof
/b which is on a different origin server by sending a `rid: 2' header not
protected by a connection header through the proxy.

Overall it looks like tight sanity checking of the responses by the
client, and deferring the use of the response for something important
(like caching, saving, certification) until all responses are received and
checked, will prevent many (maybe all?) spoofing attacks.  
But a more complete analysis is needed for sure.


OK, these are all my comments.  I only thought of some of these points
while writing the message, so the message has become a bit less structured
than I intended, for this I apologize.


Koen.

From mrobkin@hbsrx.com  Fri May 25 15:50:32 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id PAA22908 for <http-wg@cuckoo.hpl.hp.com>; Fri, 25 May 2001 15:50:31 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id PAA27162
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 25 May 2001 15:50:31 +0100 (BST)
Received: from mordor.hbsrx.com (firewall.hbsrx.com [207.87.39.194])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id PAA23292
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 25 May 2001 15:50:32 +0100 (BST)
Received: from mrobkin1 (dhcp-164.hbsrx.com [198.245.168.164])
	by mordor.hbsrx.com (8.9.3/8.9.3) with SMTP id OAA27181
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 25 May 2001 14:43:58 GMT
From: "Michael Robkin" <mrobkin@hbsrx.com>
To: <http-wg@cuckoo.hpl.hp.com>
Subject: sample http format
Date: Fri, 25 May 2001 10:48:37 -0400
Message-ID: <001801c0e529$c85c5cd0$a4a8f5c6@hbsrx.comppp.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200




  I need to write from a legacy package http formatted data to a servlet. I
will be using tcp communication.


 Can somebody send me a real life format of the actual http generated
message I must send to the

  servlet?


 is it a Post method?


               thanks,


             Michael

From fielding@ebuilt.com  Wed May 23 22:25:14 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id WAA29163 for <http-wg@cuckoo.hpl.hp.com>; Wed, 23 May 2001 22:25:13 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id WAA09140
	for <http-wg@hplb.hpl.hp.com>; Wed, 23 May 2001 22:25:08 +0100 (BST)
Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id WAA10653
	for <http-wg@hplb.hpl.hp.com>; Wed, 23 May 2001 22:25:12 +0100 (BST)
Received: (from root@localhost)
	by mutley.ebuilt.net (8.11.1/8.11.1) id f4NLBGH03043
	for <http-wg@hplb.hpl.hp.com>; Wed, 23 May 2001 14:11:16 -0700
Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199])
	by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f4NLBFp02962;
	Wed, 23 May 2001 14:11:15 -0700
Received: from localhost (fielding@localhost)
	by waka.ebuilt.net (8.11.0/8.11.0) with ESMTP id f4NLAWZ01186;
	Wed, 23 May 2001 14:10:32 -0700
Message-Id: <200105232110.f4NLAWZ01186@waka.ebuilt.net>
To: Jeff.Hodges@kingsmountain.com
cc: http-wg@hplb.hpl.hp.com
Subject: Re: wrt: Web Protocols and Practice: HTTP/1.1, Networking Protocols, Caching, and Traffic Measurement 
In-Reply-To: Your message of "Fri, 18 May 2001 09:02:03 PDT."
             <200105181602.JAA02835@breakaway.Stanford.EDU> 
Date: Wed, 23 May 2001 14:10:32 -0700
From: "Roy T. Fielding" <fielding@ebuilt.com>
X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/)

In message <200105181602.JAA02835@breakaway.Stanford.EDU>,
Jeff.Hodges@kingsmountain.com writes:
>So, have folks on this list reviewed or otherwise seen this book?..
>
>Web Protocols and Practice: HTTP/1.1, Networking Protocols, Caching,
>and Traffic Measurement 
> Balachander Krishnamurthy 
> Jennifer Rexford 
> Copyright 2001, 672 pp. 
> ISBN 0-201-71088-9
>
> http://www.awlonline.com/product/0,2627,0201710889,00.html
>
>Anyway, it sounds like it is likely a "good book" and worth having, but I'd 
>prefer to get some independent confirmation before parting with the $.

I think my review is on the back cover, but not online.  This is what
I wrote:

Web Protocols and Practice, authored by Balachander Krishnamurthy and
Jennifer Rexford, provides a comprehensive examination of the network
protocols and software implementations that have made the World Wide Web
what it is today: the most wide-spread and pervasive application of
computers ever invented.  This is the first book to delve beyond the
typical user experience of the Web and analyze the operation and behavior
of Web browsers, intermediaries, and servers in the same way that a
mechanic's manual would describe the intended operation of an automobile.
You need this book if you want to do more than than just poke around
under the hood.

Sufficient background material is provided for readers wishing to
understand the basics of the Web infrastructure, but the book will
primarily benefit those who need to know more than what is defined
in the standard Internet protocol specifications.  The chapters on
Measuring and Characterizing Web Traffic should be required reading
for anyone managing a website or developing Web software.  Likewise,
network planners and administrators will find the discussion on the
interaction between HTTP and other Internet protocols (IP, TCP, and DNS)
to be invaluable for anticipating and preventing the types of network
failure that can cause a company to fall off the Internet.


Cheers,

Roy T. Fielding, Chief Scientist, eBuilt, Inc.
                 2652 McGaw Avenue
                 Irvine, CA 92614-5840  fax:+1.949.609.0001
                 (fielding@ebuilt.com)  <http://www.eBuilt.com>

From joris.dobbelsteen@mail.com  Fri Jun  1 18:26:46 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id SAA18070 for <http-wg@cuckoo.hpl.hp.com>; Fri, 1 Jun 2001 18:26:45 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA06307
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 1 Jun 2001 18:26:42 +0100 (BST)
Received: from lepidachrosite.lion-access.net (lepidachrosite.lion-access.net [212.19.217.3])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id SAA11725
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 1 Jun 2001 18:26:43 +0100 (BST)
Received: from XTREME (1Cust92.tnt32.rtm1.nl.uu.net [213.116.158.92])
	by lepidachrosite.lion-access.net (I-Lab) with SMTP
	id 89EADCB093; Fri,  1 Jun 2001 17:21:47 +0000 (GMT)
From: "Joris Dobbelsteen" <joris.dobbelsteen@mail.com>
To: "'Michael Robkin'" <mrobkin@hbsrx.com>
Cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: RE: sample http format
Date: Fri, 1 Jun 2001 19:26:53 +0200
Message-ID: <001201c0eac0$0d89a9c0$0d0aa8c0@XTREME>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <001801c0e529$c85c5cd0$a4a8f5c6@hbsrx.comppp.net>

Michael

Please read RFC2616 regarding the HTTP/1.1 protocol. This document is the
specification that describes the protocol and should be used to implement a
HTTP/1.1 server, proxy or client. The RFC is the best starting point for
doing something with HTTP.

You can download a RFC from http://www.ietf.com/.


- Joris


-----Original Message-----
From: Michael Robkin [mailto:mrobkin@hbsrx.com]
Sent: Friday, 25 May 2001 16:49
To: http-wg@cuckoo.hpl.hp.com
Subject: sample http format





  I need to write from a legacy package http formatted data to a servlet. I
will be using tcp communication.


 Can somebody send me a real life format of the actual http generated
message I must send to the

  servlet?


 is it a Post method?


               thanks,


             Michael


From bala@research.att.com  Mon May 28 21:05:18 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id VAA26826 for <http-wg@cuckoo.hpl.hp.com>; Mon, 28 May 2001 21:05:17 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id VAA18440
	for <http-wg@hplb.hpl.hp.com>; Mon, 28 May 2001 21:05:17 +0100 (BST)
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id VAA20040
	for <http-wg@hplb.hpl.hp.com>; Mon, 28 May 2001 21:05:21 +0100 (BST)
Received: from raptor.research.att.com (raptor.research.att.com [135.207.23.32])
	by mail-blue.research.att.com (Postfix) with ESMTP id 9D8934CED2
	for <http-wg@hplb.hpl.hp.com>; Mon, 28 May 2001 16:03:58 -0400 (EDT)
Received: from localhost (bala@localhost)
	by raptor.research.att.com (SGI-8.9.3/8.8.7) with SMTP id QAA56734
	for <http-wg@hplb.hpl.hp.com>; Mon, 28 May 2001 16:03:58 -0400 (EDT)
Message-Id: <200105282003.QAA56734@raptor.research.att.com>
X-Authentication-Warning: raptor.research.att.com: bala@localhost didn't use HELO protocol
To: http-wg@hplb.hpl.hp.com
Subject: call for papers: Internet Measurement Workshop
Date: Mon, 28 May 2001 16:03:58 -0400
From: Balachander Krishnamurthy <bala@research.att.com>


ACM SIGCOMM Internet Measurement Workshop 2001
November 1-2, 2001
San Francisco Bay Area

This ACM SIGCOMM Internet Measurement Workshop is a one and a half 
day event focusing on Internet measurement and analysis. Submissions 
should contribute to the current understanding of how to collect or 
analyze Internet measurements, or give insight into how the Internet 
behaves. Examples of relevant topics are:

	* Workload characterization
	* Traffic engineering
	* Web measurements
	* Inter-domain and intra-domain routing
	* Active measurement techniques
	* Passive measurement techniques
	* Anonymization/privacy issues
	* Calibration
	* Measurement-based inference of network properties
	* Efficacy of content distribution networks
	* Reassessment/testing of previous measurement findings
	* Assessment of previous simulation/testbed findings

Submissions on new ideas and work-in-progress are encouraged. Papers
that do not in some fashion rely on measuring Internet properties are
out of scope.

The workshop is sponsored by ACM SIGCOMM.  In addition to the published
proceedings, the Program Committee may also select a few papers for
fast-track submission for possible publication in IEEE/ACM Transactions
on Networking.

Attendance will be limited to 50 participants, with priority given to
authors of accepted papers, program committee members, and authors of
submitted papers.

The workshop is open to three forms of submissions:

* full papers (up to 15 pages) should exhibit succinctness appropriate 
  to the topics and themes they discuss.

* extended abstracts (up to 4 pages), conveying work expected to mature
  somewhat between submission and presentation at the workshop.

* brief abstracts (less than a single page) to be considered for a 
  possible work-in-progress session.

Submissions must be in electronic form, as plain text, Postscript,
or PDF documents, following the instructions found at:

        http://www.aciri.org/vern/sigcomm-imeas-2001.submit.html

All manuscripts must be in English. The top of the first page of each
paper should include the title of the paper, the authors and their
affiliations, and the full address for the contact author (e-mail, 
phone, fax, mailing address).

Papers and extended abstracts accepted for presentation at the workshop
will be published by ACM in proceedings.

Important dates
---------------

        June 29, 2001: HARD submission deadline 
	August 3, 2001: Notification
	August 31, 2001: Camera Ready Copy due

Steering committee
------------------
Christophe Diot, Sprint ATL (cdiot@sprintlabs.com)
Balachander Krishnamurthy, AT&T--Labs Research (bala@research.att.com)
Vern Paxson, ACIRI (vern@aciri.org)
Jennifer Rexford, AT&T--Labs Research (jrex@research.att.com)

Program committee
-----------------

Mark Allman (NASA GRC, USA)
Martin Arlitt (Hewlett-Packard Labs, USA)
Paul Barford (U. of Wisconsin, USA)
Anja Feldmann (Univ. Saarbruecken, Germany)
Geoff Huston (Telstra, Australia)
Jeffrey Mogul (Compaq WRL, USA)
Henk Uijterwaal (RIPE NCC, Netherlands)

From tapan_divekar@hotmail.com  Fri Jun  1 19:21:10 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id TAA19341 for <http-wg@cuckoo.hpl.hp.com>; Fri, 1 Jun 2001 19:21:09 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id TAA08076
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 1 Jun 2001 19:21:09 +0100 (BST)
Received: from hotmail.com (f247.law8.hotmail.com [216.33.241.247])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id TAA12960
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 1 Jun 2001 19:21:13 +0100 (BST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 1 Jun 2001 11:20:12 -0700
Received: from 128.227.170.186 by lw8fd.law8.hotmail.msn.com with HTTP;	Fri, 01 Jun 2001 18:20:12 GMT
X-Originating-IP: [128.227.170.186]
From: "Tapan Divekar" <tapan_divekar@hotmail.com>
To: http-wg@cuckoo.hpl.hp.com
Subject: http over udp?
Date: Fri, 01 Jun 2001 18:20:12 -0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F247UMjA2QUg6A7oPiF0000fbbc@hotmail.com>
X-OriginalArrivalTime: 01 Jun 2001 18:20:12.0313 (UTC) FILETIME=[7F659890:01C0EAC7]

has anyone tried to use http over udp.
i have a device which has only udp type server sockets. it doenst have TCP 
ones.
I want to reach that device using netscape/ IE (any browser).
since HTTP is based over TCP , my UDP listener at my device's end wont 
receive packets sent over netscape.

Any ideas?
Thanks
Tapan
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

From joris.dobbelsteen@mail.com  Mon Jun  4 15:42:07 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id PAA26853 for <http-wg@cuckoo.hpl.hp.com>; Mon, 4 Jun 2001 15:42:06 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id PAA09676
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 4 Jun 2001 15:42:05 +0100 (BST)
Received: from lepidachrosite.lion-access.net (lepidachrosite.lion-access.net [212.19.217.3])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id PAA19269
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 4 Jun 2001 15:42:10 +0100 (BST)
Received: from XTREME (1Cust41.tnt33.rtm1.nl.uu.net [213.116.160.41])
	by lepidachrosite.lion-access.net (I-Lab) with SMTP
	id 9AD40CB058; Mon,  4 Jun 2001 14:37:10 +0000 (GMT)
From: "Joris Dobbelsteen" <joris.dobbelsteen@mail.com>
To: "'Tapan Divekar'" <tapan_divekar@hotmail.com>
Cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: RE: http over udp?
Date: Mon, 4 Jun 2001 16:42:23 +0200
Message-ID: <000801c0ed04$91ee0080$0d0aa8c0@joris2k.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <F247UMjA2QUg6A7oPiF0000fbbc@hotmail.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

The issue is that HTTP needs a connection-oriented transport.
Using UDP would mean that you need some sort of connection-management...

So why use UDP?

Note that UDP is a complete different protocol than TCP, even if they have
the same range of port numbers (and have ports).

- Joris

-----Original Message-----
From: Tapan Divekar [mailto:tapan_divekar@hotmail.com]
Sent: Friday, 01 June 2001 20:20
To: http-wg@cuckoo.hpl.hp.com
Subject: http over udp?


has anyone tried to use http over udp.
i have a device which has only udp type server sockets. it doenst have TCP
ones.
I want to reach that device using netscape/ IE (any browser).
since HTTP is based over TCP , my UDP listener at my device's end wont
receive packets sent over netscape.

Any ideas?
Thanks
Tapan
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

From douglis@research.att.com  Mon Jun  4 16:54:56 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id QAA28447 for <http-wg@cuckoo.hpl.hp.com>; Mon, 4 Jun 2001 16:54:55 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA12813
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 4 Jun 2001 16:54:54 +0100 (BST)
Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id QAA21993
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 4 Jun 2001 16:54:59 +0100 (BST)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-green.research.att.com (Postfix) with ESMTP
	id 052861E41A; Mon,  4 Jun 2001 11:53:36 -0400 (EDT)
Received: from douglux.research.att.com (root@douglux.research.att.com [135.207.26.106])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA16097;
	Mon, 4 Jun 2001 11:53:35 -0400 (EDT)
Received: from douglux.research.att.com (IDENT:douglis@localhost.localdomain [127.0.0.1])
	by douglux.research.att.com (8.9.3/8.9.3) with ESMTP id LAA25689;
	Mon, 4 Jun 2001 11:53:35 -0400
Message-Id: <200106041553.LAA25689@douglux.research.att.com>
X-Mailer: exmh version 2.1.1 10/15/1999
From: Fred Douglis <douglis@research.att.com>
To: "Joris Dobbelsteen" <joris.dobbelsteen@mail.com>
Cc: "'Tapan Divekar'" <tapan_divekar@hotmail.com>,
        "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>, misha@research.att.com
Subject: Re: http over udp? 
In-reply-to: Your message of "Mon, 04 Jun 2001 16:42:23 +0200."
             <000801c0ed04$91ee0080$0d0aa8c0@joris2k.local> 
X-URI: http://www.research.att.com/~douglis/
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 04 Jun 2001 11:53:35 -0400
Sender: douglis@research.att.com

A few people have investigated the use of HTTP over UDP rather than TCP, 
useful for short files as a way of bypassing TCP startup overheads.  The most 
recent such work of which I'm aware was in the last Infocom.  See

http://www.research.att.com/~misha/dhttp/abstract.html
 
Fred

From tapan_divekar@hotmail.com  Mon Jun  4 18:20:05 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id SAA29972 for <http-wg@cuckoo.hpl.hp.com>; Mon, 4 Jun 2001 18:20:04 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA15789
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 4 Jun 2001 18:20:03 +0100 (BST)
Received: from hotmail.com (f122.law8.hotmail.com [216.33.241.122])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id SAA24533
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 4 Jun 2001 18:20:08 +0100 (BST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 4 Jun 2001 10:19:03 -0700
Received: from 128.227.170.186 by lw8fd.law8.hotmail.msn.com with HTTP;	Mon, 04 Jun 2001 17:19:02 GMT
X-Originating-IP: [128.227.170.186]
From: "Tapan Divekar" <tapan_divekar@hotmail.com>
To: joris.dobbelsteen@mail.com
Cc: http-wg@cuckoo.hpl.hp.com
Subject: RE: http over udp?
Date: Mon, 04 Jun 2001 17:19:02 -0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F122lO61PotcFW6XH4F00008dba@hotmail.com>
X-OriginalArrivalTime: 04 Jun 2001 17:19:03.0176 (UTC) FILETIME=[73A8F880:01C0ED1A]


Hi Joris,

>
>The issue is that HTTP needs a connection-oriented transport.
>Using UDP would mean that you need some sort of connection-management...
>
>So why use UDP?
I have a device that supports only UDP kind of server side sockets.
So I have to use UDP.


>
>Note that UDP is a complete different protocol than TCP, even if they have
>the same range of port numbers (and have ports).
Yes, I know , but since I had to use UDP, I was thinking on that track
Tapan

>
>- Joris
>
>-----Original Message-----
>From: Tapan Divekar [mailto:tapan_divekar@hotmail.com]
>Sent: Friday, 01 June 2001 20:20
>To: http-wg@cuckoo.hpl.hp.com
>Subject: http over udp?
>
>
>has anyone tried to use http over udp.
>i have a device which has only udp type server sockets. it doenst have TCP
>ones.
>I want to reach that device using netscape/ IE (any browser).
>since HTTP is based over TCP , my UDP listener at my device's end wont
>receive packets sent over netscape.
>
>Any ideas?
>Thanks
>Tapan
>_________________________________________________________________________
>Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
>

From peterw@rcn.com  Fri Jun  8 00:22:51 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id AAA07222 for <http-wg@cuckoo.hpl.hp.com>; Fri, 8 Jun 2001 00:22:50 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id AAA11288
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 8 Jun 2001 00:22:50 +0100 (BST)
Received: from rcn.com (208-58-64-251.c3-0.129-ubr1.lnh-129.md.cable.rcn.com [208.58.64.251])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id AAA20591
	for <http-wg@cuckoo.hpl.hp.com>; Fri, 8 Jun 2001 00:22:54 +0100 (BST)
Received: (from peterw@localhost)
	by rcn.com (Mail Server) id TAA13987
	for http-wg@cuckoo.hpl.hp.com; Thu, 7 Jun 2001 19:21:45 -0400
Date: Thu, 7 Jun 2001 19:21:45 -0400
From: Peter W <peterw@usa.net>
To: http-wg@cuckoo.hpl.hp.com
Subject: %NN encoding, request/response headers, UTF-8 ?
Message-ID: <20010607192145.A13796@usa.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i

I'm curious 
 - whether Unicode characters with values 0x100 and greater are allowed in 
   request headers (especially the request line)
 - if so, if UTF-8 encoding is allowed
 - how a client indicates to the server that it's using UTF-8
 - how an HTTP server application decides how to interpret
   hex-encoded information, e.g. is %C3%B1 encoding two characters,
   or the UTF-8 encoding for the single character "ñ"
 - how/if a server might use UTF-8 in its response headers

It looks like any content that is sent with MIME headers (e.g., an object 
sent by the HTTP server) could be announced with a charset value indicating 
UTF-8 encoding, but that headers (request or response) are only expected to 
contain characters 0x00 -> 0xFF. Yet I don't see this clearly stated.

It seems fairly clear, though, that double-byte character sets (e.g., 16
bits for each character regardless of its value) should not be used in
either request or response headers. Right?

I appreciate any light you may be able to shed on this topic.

-Peter
http://www.tux.org/~peterw/

From joris.dobbelsteen@mail.com  Sun Jun 10 23:12:33 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id XAA10862 for <http-wg@cuckoo.hpl.hp.com>; Sun, 10 Jun 2001 23:12:33 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id XAA10345
	for <http-wg@cuckoo.hpl.hp.com>; Sun, 10 Jun 2001 23:12:33 +0100 (BST)
Received: from lepidachrosite.lion-access.net (lepidachrosite.lion-access.net [212.19.217.3])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id XAA02726
	for <http-wg@cuckoo.hpl.hp.com>; Sun, 10 Jun 2001 23:12:33 +0100 (BST)
Received: from XTREME (1Cust11.tnt53.rtm1.nl.uu.net [213.117.24.11])
	by lepidachrosite.lion-access.net (I-Lab) with SMTP
	id C28BFCB08F; Sun, 10 Jun 2001 22:07:33 +0000 (GMT)
From: "Joris Dobbelsteen" <joris.dobbelsteen@mail.com>
To: "'Tapan Divekar'" <tapan_divekar@hotmail.com>
Cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: RE: http over udp?
Date: Mon, 11 Jun 2001 00:13:03 +0200
Message-ID: <000601c0f1fa$85074ca0$0d0ba8c0@joris2k.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <F143SOlbpH71yEXUIEA000142be@hotmail.com>
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

Quite a late response, but I didn't have time earlier...

------Original Message-----
>From: Tapan Divekar [mailto:tapan_divekar@hotmail.com]
>Sent: Thursday, 07 June 2001 16:43
>To: joris.dobbelsteen@mail.com
>Subject: RE: http over udp?
>
>
>
>Hi Joris
>Thanks for the email. I would appreciate if you could answer
>my questions.
>>The issue is that you need some kind of session-management for the
>>'requests'. Having this solves requests over UDP greater than
>64KB and such
>>transmission back. Also, the client needs to know what it's
>requests are.
>>This is required in the case of multiple requests.
>>
>
>
>
>Im quite new as far as working of HTTP protocol is concerned..
>Could you pl.
>tell me more about the session mgmt protocol here?
>Is 64kb is a bottleneck for the UDP requests?
>
Depends on what you want. Relatively small HTML pages, some art and stuff
usually keep below 64kb, but there are pages that are way larger, and this
is even more common for art. Not to talk about downloads or IE's extensions,
like ActiveX Controls
>
>>The proposal on the ATT research site, still relies on TCP, however:
>>connections are made by the server rather than the client. So
>STILL TCP!!!
>>not solely UDP.
>>
>>A nice feature would be the easy implementation of HOL
>blocking / async
>>transfers of all files.
>
>Could you please elaborate more on this?
>
HOL blocking stands for Head-Of-Line Blocking: meaning if you send two
requests (using one connection-persistent connection) using TCP, one for a
large PDF file and another for a small image file, then first the large PDF
file must be downloaded before you can get the image. If you send the image
first and then the PDF file, this would be much nicer in some instances.

>
>Also it's nice for transports that can have packet
>>drops: live audio/video. But for this there are other
>protocols that do
>>better than HTTP.
>
>Which protocols other than HTTP would you consider better here? TCP?
>
No, MMS (Microsoft), RTSP (Apple Quicktime, Realplayer). These are designed
solely for audio/video and work on UDP/TCP and support multicast.
I hope you understand how IP, UDP, TCP, HTTP, ..... are related to
eachother...

IP is designed for addressing computers and routing requests easily.
TCP is a connection-based reliable protocol that works on top of IP.
UDP is a connection-less unreliable datagram protocol that works on top of
IP.
HTTP is a application protocol that usually works on top of TCP.

>
>
>>Next you need enourmes time-outs, since you don't know
>whether a server is
>>still handling your request or crashed or 'bobby' knows what else...
>>
>
>Ya, thats true
>Thanks a lot.. appreciate your help
>Tapan
>
>>
>>- Joris
>>
>

- Joris

From derhoermi@gmx.net  Sat Jun 16 02:18:53 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id CAA14020 for <http-wg@cuckoo.hpl.hp.com>; Sat, 16 Jun 2001 02:18:52 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id CAA13627
	for <http-wg@cuckoo.hpl.hp.com>; Sat, 16 Jun 2001 02:18:51 +0100 (BST)
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with SMTP id CAA18507
	for <http-wg@cuckoo.hpl.hp.com>; Sat, 16 Jun 2001 02:18:57 +0100 (BST)
Received: (qmail 5256 invoked by uid 0); 16 Jun 2001 01:17:15 -0000
Received: from pd903b34f.dip.t-dialin.net (217.3.179.79)
  by mail.gmx.net (mp030-rz3) with SMTP; 16 Jun 2001 01:17:15 -0000
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Peter W <peterw@usa.net>
Cc: http-wg@cuckoo.hpl.hp.com
Subject: Re: %NN encoding, request/response headers, UTF-8 ?
Date: Sat, 16 Jun 2001 03:18:45 +0200
Organization: Web Programming and IT Development Guru [tm]
Reply-To: Bjoern Hoehrmann <derhoermi@gmx.net>
Message-ID: <spclitg78v37pl3ue3n9ibbganto7n4jn7@4ax.com>
References: <20010607192145.A13796@usa.net>
In-Reply-To: <20010607192145.A13796@usa.net>
X-Mailer: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

* Peter W wrote:
>I'm curious 
> - whether Unicode characters with values 0x100 and greater are allowed in 
>   request headers (especially the request line)

This depends on RFC 2396 which only allows US-ASCII characters, i.e.
U+0000-U+007F minus further restrictions on URI syntax.

>It seems fairly clear, though, that double-byte character sets (e.g., 16
>bits for each character regardless of its value) should not be used in
>either request or response headers. Right?

They cannot.

Take a look at IRIs,
http://www.ietf.org/internet-drafts/draft-masinter-url-i18n-07.txt
-- 
Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/

From joris.dobbelsteen@mail.com  Sun Jun 10 23:20:22 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id XAA11867 for <http-wg@cuckoo.hpl.hp.com>; Sun, 10 Jun 2001 23:20:22 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id XAA10648
	for <http-wg@cuckoo.hpl.hp.com>; Sun, 10 Jun 2001 23:20:21 +0100 (BST)
Received: from lepidachrosite.lion-access.net (lepidachrosite.lion-access.net [212.19.217.3])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id XAA03049
	for <http-wg@cuckoo.hpl.hp.com>; Sun, 10 Jun 2001 23:20:27 +0100 (BST)
Received: from XTREME (1Cust11.tnt53.rtm1.nl.uu.net [213.117.24.11])
	by lepidachrosite.lion-access.net (I-Lab) with SMTP
	id 58DC7CB048; Sun, 10 Jun 2001 22:15:32 +0000 (GMT)
From: "Joris Dobbelsteen" <joris.dobbelsteen@mail.com>
To: "'Peter W'" <peterw@usa.net>
Cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: RE: %NN encoding, request/response headers, UTF-8 ?
Date: Mon, 11 Jun 2001 00:21:01 +0200
Message-ID: <000701c0f1fb$a263f900$0d0ba8c0@joris2k.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <20010607192145.A13796@usa.net>
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

They are still used, I think.... (e.g. IE)

The specification expects ASCII characters, but if UTF-8 is compatible with
ASCII and the spec this can be used.

>-----Original Message-----
>From: Peter W [mailto:peterw@usa.net]
>Sent: Friday, 08 June 2001 1:22
>To: http-wg@cuckoo.hpl.hp.com
>Subject: %NN encoding, request/response headers, UTF-8 ?
>
>
>I'm curious
> - whether Unicode characters with values 0x100 and greater
>are allowed in
>   request headers (especially the request line)

No, solely ASCII, according to the spec. It states ASCII characters, with a
range from 0x00 to 0xFF. Depending on what you are entering, there may be
some more limitations (see spec).

> - if so, if UTF-8 encoding is allowed\

Don't know about UTF-8, I thought IE could use it to encode the URL.

> - how a client indicates to the server that it's using UTF-8
> - how an HTTP server application decides how to interpret
>   hex-encoded information, e.g. is %C3%B1 encoding two characters,
>   or the UTF-8 encoding for the single character "ñ"
> - how/if a server might use UTF-8 in its response headers
>
>It looks like any content that is sent with MIME headers
>(e.g., an object
>sent by the HTTP server) could be announced with a charset
>value indicating
>UTF-8 encoding, but that headers (request or response) are
>only expected to
>contain characters 0x00 -> 0xFF. Yet I don't see this clearly stated.
>
>It seems fairly clear, though, that double-byte character sets
>(e.g., 16
>bits for each character regardless of its value) should not be used in
>either request or response headers. Right?

Seems like it. It might, however, be possible to encode them so they comply
with the spec. Still, I'm not sure about this.

>
>I appreciate any light you may be able to shed on this topic.
>
>-Peter
>http://www.tux.org/~peterw/
>

- Joris
>

From derhoermi@gmx.net  Sat Jun 16 02:19:52 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id CAA14052 for <http-wg@cuckoo.hpl.hp.com>; Sat, 16 Jun 2001 02:19:50 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id CAA13652
	for <http-wg@cuckoo.hpl.hp.com>; Sat, 16 Jun 2001 02:19:50 +0100 (BST)
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with SMTP id CAA18546
	for <http-wg@cuckoo.hpl.hp.com>; Sat, 16 Jun 2001 02:19:55 +0100 (BST)
Received: (qmail 22527 invoked by uid 0); 16 Jun 2001 01:18:17 -0000
Received: from pd903b34f.dip.t-dialin.net (217.3.179.79)
  by mail.gmx.net (mail01) with SMTP; 16 Jun 2001 01:18:17 -0000
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: "Joris Dobbelsteen" <joris.dobbelsteen@mail.com>
Cc: "'Peter W'" <peterw@usa.net>,
        "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: Re: %NN encoding, request/response headers, UTF-8 ?
Date: Sat, 16 Jun 2001 03:19:47 +0200
Organization: Web Programming and IT Development Guru [tm]
Reply-To: Bjoern Hoehrmann <derhoermi@gmx.net>
Message-ID: <10dlitcdm73e3b6qcorltk4lc9vvgojpob@4ax.com>
References: <20010607192145.A13796@usa.net> <000701c0f1fb$a263f900$0d0ba8c0@joris2k.local>
In-Reply-To: <000701c0f1fb$a263f900$0d0ba8c0@joris2k.local>
X-Mailer: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

* Joris Dobbelsteen wrote:
>No, solely ASCII, according to the spec. It states ASCII characters, with a
>range from 0x00 to 0xFF. Depending on what you are entering, there may be
>some more limitations (see spec).

US-ASCII doesn't define anything above 0x7F.
-- 
Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/

From LMM@acm.org  Sat Jun 16 17:07:42 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id RAA27220 for <http-wg@cuckoo.hpl.hp.com>; Sat, 16 Jun 2001 17:07:41 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id RAA14001
	for <http-wg@cuckoo.hpl.hp.com>; Sat, 16 Jun 2001 17:07:40 +0100 (BST)
Received: from smtp-relay-1.Adobe.COM (smtp-relay-1.adobe.com [192.150.11.1])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id RAA24809
	for <http-wg@cuckoo.hpl.hp.com>; Sat, 16 Jun 2001 17:07:44 +0100 (BST)
Received: from inner-relay-2.Adobe.COM (inner-relay-2.corp.adobe.com [153.32.1.52])
	by smtp-relay-1.Adobe.COM (8.8.6) with ESMTP id JAA28093
	for <http-wg@cuckoo.hpl.hp.com>; Sat, 16 Jun 2001 09:07:05 -0700 (PDT)
Received: from mailsj-v1.corp.adobe.com  by inner-relay-2.Adobe.COM (8.8.5) with ESMTP id JAA07473; Sat, 16 Jun 2001 09:03:26 -0700 (PDT)
Received: from larrypad ([130.248.184.177]) by
          mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15) with
          SMTP id GF15Y100.66V; Sat, 16 Jun 2001 09:03:37 -0700 
From: "Larry Masinter" <LMM@acm.org>
To: "Peter W" <peterw@usa.net>
Cc: <http-wg@cuckoo.hpl.hp.com>,
        "=?iso-8859-1?Q?Martin_J._D=FCrst?=" <duerst@w3.org>
Subject: RE: %NN encoding, request/response headers, UTF-8 ?
Date: Sat, 16 Jun 2001 09:02:54 -0700
Message-ID: <NDBBKEBDLFENBJCGFOIJCELOFBAA.LMM@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <20010607192145.A13796@usa.net>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

>  - whether Unicode characters with values 0x100 and greater are allowed in
>    request headers (especially the request line)
>  - if so, if UTF-8 encoding is allowed

The "request line" and "request headers" are different contexts.
If you're thinking about using IRIs as the request URI
  (draft-masinter-uri-i18n-07.txt)
it is still necessary to convert the IRI to a URI before using it
in the HTTP protocol, because the HTTP protocol only uses URIs
which have a restricted character repertoire.

>  - how a client indicates to the server that it's using UTF-8

depends on the context

>  - how an HTTP server application decides how to interpret
>    hex-encoded information, e.g. is %C3%B1 encoding two characters,
>    or the UTF-8 encoding for the single character "ñ"

The hex-encoding is only used for URIs and not for other elements,
and what it encodes depends entirely on the server that serves it.
This is entirely server-dependent, and %C3%B1 might represent
something entirely different, not characters at all. There is
no restriction that encoding in URIs actually corresponds to
character data.


>  - how/if a server might use UTF-8 in its response headers
> It looks like any content that is sent with MIME headers (e.g., an object
> sent by the HTTP server) could be announced with a charset value indicating
> UTF-8 encoding, but that headers (request or response) are only expected to
> contain characters 0x00 -> 0xFF. Yet I don't see this clearly stated.


Some response headers allow TEXT, e.g., on comments.

RFC 2616 section 14.46 (description of Warning header)

   If a character set other than ISO-8859-1 is used, it MUST be encoded
   in the warn-text using the method described in RFC 2047 [14].

RFC 2616, section 2.2, Basic Rules:
       OCTET          = <any 8-bit sequence of data>
       CHAR           = <any US-ASCII character (octets 0 - 127)>

...

   The TEXT rule is only used for descriptive field contents and values
   that are not intended to be interpreted by the message parser. Words
   of *TEXT MAY contain characters from character sets other than ISO-
   8859-1 [22] only when encoded according to the rules of RFC 2047
   [14].

       TEXT           = <any OCTET except CTLs,
                        but including LWS>

This means that you can use UTF-16 if you first base64 encode it
and then use it within the RFC 2047 method, viz
                =?UTF-8?b?<base64string>?=


> It seems fairly clear, though, that double-byte character sets (e.g., 16
> bits for each character regardless of its value) should not be used in
> either request or response headers. Right?

Not without some kind of encoding, but the encoding rules differ
according to the context.

Larry
--
http://larry.masinter.net

From Daniel.Veilleux@LibertyMutual.com  Tue Jun 26 14:17:28 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id OAA25368 for <http-wg@cuckoo.hpl.hp.com>; Tue, 26 Jun 2001 14:17:28 +0100 (BST)
From: Daniel.Veilleux@LibertyMutual.com
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id OAA02382
	for <http-wg@cuckoo.hpl.hp.com>; Tue, 26 Jun 2001 14:17:27 +0100 (BST)
Received: from lmig-ims-01.lmig.com (lmig-ims-01.libertymutual.com [143.115.171.233])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id OAA28988
	for <http-wg@cuckoo.hpl.hp.com>; Tue, 26 Jun 2001 14:17:32 +0100 (BST)
Received: by lmig-ims-01.lmig.com with Internet Mail Service (5.5.2653.19)
	id <LFWAMQXY>; Tue, 26 Jun 2001 09:16:02 -0400
Message-ID: <4D3504A6257FD31194FD00508B139C1402FB8F10@lmig-msg-01.lmig.com>
To: http-wg@cuckoo.hpl.hp.com
Subject: How do I get a directory listing using a HTTP Get
Date: Tue, 26 Jun 2001 09:15:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain


I would like to write a program that goes to a web site and does an HTTP GET
and instead of coming back with an HTML page, I would like to come back with
a directory listing of files.  The HTML page will contain links to the files
in the same directory but instead of having to parse the HTML page for the
file names I would like to just get a directory listing as this would make
the downloading of these files easier.  Does anyone know of a way to do
this?

Dan Veilleux
Electronic Commerce
Liberty Mutual

From francis@ecal.com  Tue Jun 26 15:32:45 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id PAA27483 for <http-wg@cuckoo.hpl.hp.com>; Tue, 26 Jun 2001 15:32:43 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id PAA05506
	for <http-wg@cuckoo.hpl.hp.com>; Tue, 26 Jun 2001 15:32:41 +0100 (BST)
Received: from localhost.localdomain ([216.52.68.3])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id PAA01491
	for <http-wg@cuckoo.hpl.hp.com>; Tue, 26 Jun 2001 15:32:46 +0100 (BST)
Received: from ecal.com (localhost [127.0.0.1])
	by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f5QEXQC02510;
	Tue, 26 Jun 2001 10:33:26 -0400
Sender: francis@localhost.localdomain
Message-ID: <3B389D36.5784554E@ecal.com>
Date: Tue, 26 Jun 2001 10:33:26 -0400
From: John Stracke <francis@ecal.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i586)
X-Accept-Language: en, de, es
MIME-Version: 1.0
To: Daniel.Veilleux@LibertyMutual.com
CC: http-wg@cuckoo.hpl.hp.com
Subject: Re: How do I get a directory listing using a HTTP Get
References: <4D3504A6257FD31194FD00508B139C1402FB8F10@lmig-msg-01.lmig.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Daniel.Veilleux@LibertyMutual.com wrote:

> I would like to write a program that goes to a web site and does an HTTP GET
> and instead of coming back with an HTML page, I would like to come back with
> a directory listing of files.

This can't happen unless the server permits it.  If you have control of the
server, look into WebDAV (RFC-2518, http://www.webdav.org), which lets you use
a PROPFIND method to list the files.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"You're nothing but a pack of ringleaders!"  |
|francis@ecal.com|--_Wyrd Sisters_, Terry Pratchett            |
\==============================================================/

From RSchilling@affiliatedhealth.org  Tue Jun 26 18:31:40 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id SAA29548 for <http-wg@cuckoo.hpl.hp.com>; Tue, 26 Jun 2001 18:31:40 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA12617
	for <http-wg@cuckoo.hpl.hp.com>; Tue, 26 Jun 2001 18:31:39 +0100 (BST)
Received: from ughmail1.affiliatedhealth.org (mail1.affiliatedhealth.com [209.84.248.71])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id SAA06481
	for <http-wg@cuckoo.hpl.hp.com>; Tue, 26 Jun 2001 18:31:44 +0100 (BST)
Received: by mail1.affiliatedhealth.org with Internet Mail Service (5.5.2653.19)
	id <KT7VSDSS>; Tue, 26 Jun 2001 10:32:30 -0700
Message-ID: <51FCCCF0C130D211BE550008C724149E011656A1@mail1.affiliatedhealth.org>
From: "Schilling, Richard" <RSchilling@affiliatedhealth.org>
To: "'http-wg@cuckoo.hpl.hp.com'" <http-wg@cuckoo.hpl.hp.com>
Subject: RE: How do I get a directory listing using a HTTP Get
Date: Tue, 26 Jun 2001 10:32:29 -0700
X-Mailer: Internet Mail Service (5.5.2653.19)


You might try setting up a CGI script that gets the directory information
and sends it back as plain text.  Your program can then open a socket to the
web server, and read the list of returned files like a text file.  Really
easy to do in Java.


Richard Schilling
Webmaster / Web Integration Programmer
Affiliated Health Services
Mount Vernon, WA USA
http://www.affiliatedhealth.org
phone: 360.856.7129


> -----Original Message-----
> From: Daniel.Veilleux@LibertyMutual.com
> [mailto:Daniel.Veilleux@LibertyMutual.com]
> Sent: Tuesday, June 26, 2001 6:16 AM
> To: http-wg@cuckoo.hpl.hp.com
> Subject: How do I get a directory listing using a HTTP Get
> 
> 
> 
> I would like to write a program that goes to a web site and 
> does an HTTP GET
> and instead of coming back with an HTML page, I would like to 
> come back with
> a directory listing of files.  The HTML page will contain 
> links to the files
> in the same directory but instead of having to parse the HTML 
> page for the
> file names I would like to just get a directory listing as 
> this would make
> the downloading of these files easier.  Does anyone know of a 
> way to do
> this?
> 
> Dan Veilleux
> Electronic Commerce
> Liberty Mutual
> 

From manishksinghal@hotmail.com  Mon Jul  2 11:13:42 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id LAA19053 for <http-wg@cuckoo.hpl.hp.com>; Mon, 2 Jul 2001 11:13:41 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id LAA28200
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 2 Jul 2001 11:13:41 +0100 (BST)
Received: from hotmail.com (f79.law11.hotmail.com [64.4.17.79])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id LAA00725
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 2 Jul 2001 11:13:34 +0100 (BST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 2 Jul 2001 03:12:20 -0700
Received: from 202.9.179.16 by lw11fd.law11.hotmail.msn.com with HTTP;	Mon, 02 Jul 2001 10:12:20 GMT
X-Originating-IP: [202.9.179.16]
From: "manish kumar" <manishksinghal@hotmail.com>
To: http-wg@cuckoo.hpl.hp.com
Subject: doubt regarding http 1.1
Date: Mon, 02 Jul 2001 10:12:20 -0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F79H71yEXUIEAOeIiGX00013acc@hotmail.com>
X-OriginalArrivalTime: 02 Jul 2001 10:12:20.0643 (UTC) FILETIME=[7AED7730:01C102DF]

Hi
I am using http 1.1.I am making a persistent connection from java client to 
apache server.I am able to make it but I don't want to use transfer encoding 
as chunked(which is there by default).Is there any way I can do it.Where I 
need to change it.If you need some more detail please let me know.

-Manish
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

From joris.dobbelsteen@mail.com  Mon Jul  2 12:15:52 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id MAA20728 for <http-wg@cuckoo.hpl.hp.com>; Mon, 2 Jul 2001 12:15:52 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id MAA00889
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 2 Jul 2001 12:15:51 +0100 (BST)
Received: from rubellite.lion-access.net (rubellite.lion-access.net [212.19.217.4])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id MAA04792
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 2 Jul 2001 12:15:57 +0100 (BST)
Received: from XTREME (1Cust189.tnt33.rtm1.nl.uu.net [213.116.160.189])
	by rubellite.lion-access.net (I-Lab) with SMTP id 3832729B3
	for <http-wg@cuckoo.hpl.hp.com>; Mon,  2 Jul 2001 11:10:58 +0000 (GMT)
From: "Joris Dobbelsteen" <joris.dobbelsteen@mail.com>
To: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: RE: doubt regarding http 1.1
Date: Mon, 2 Jul 2001 13:16:46 +0200
Message-ID: <000301c102e8$7b799b80$0d0ba8c0@joris2k.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <F79H71yEXUIEAOeIiGX00013acc@hotmail.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

Why not use it? It provided a way to keep the connection open.

You can try Tranfer-Encoding: identify
see RFC2616 par. 14.41

There is also something with TE (par. 14.39).

Note that Apache will need to cache the response before transmitting it, to
demitrade the length. I don't know wether they do or support that (probably
they do). It requires only an enormous ammount of overhead on the server,
not caused with chunked transfers. So why not use these, it's simple to
build some support for that.

Before to forget, RFC2616 lists enough information in the sections with
tranfer-codings and such....


Have fun...

- Joris

>-----Original Message-----
>From: manish kumar [mailto:manishksinghal@hotmail.com]
>Sent: Monday, 02 July 2001 12:12
>To: http-wg@cuckoo.hpl.hp.com
>Subject: doubt regarding http 1.1
>
>
>Hi
>I am using http 1.1.I am making a persistent connection from
>java client to
>apache server.I am able to make it but I don't want to use
>transfer encoding
>as chunked(which is there by default).Is there any way I can
>do it.Where I
>need to change it.If you need some more detail please let me know.
>
>-Manish
>_______________________________________________________________
>__________
>Get Your Private, Free E-mail from MSN Hotmail at
http://www.hotmail.com.


From mnot@mnot.net  Mon Jul  2 19:48:23 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id TAA23091 for <http-wg@cuckoo.hpl.hp.com>; Mon, 2 Jul 2001 19:48:23 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id TAA18196
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 2 Jul 2001 19:48:22 +0100 (BST)
Received: from mail.mnot.net ([64.170.196.242])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id TAA11281
	for <http-wg@cuckoo.hpl.hp.com>; Mon, 2 Jul 2001 19:48:27 +0100 (BST)
Received: by mail.mnot.net (Postfix, from userid 500)
	id F3A28976D; Mon,  2 Jul 2001 11:34:18 -0700 (PDT)
Date: Mon, 2 Jul 2001 11:34:18 -0700
From: Mark Nottingham <mnot@mnot.net>
To: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
Cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: Re: doubt regarding http 1.1
Message-ID: <20010702113415.B27968@mnot.net>
References: <F79H71yEXUIEAOeIiGX00013acc@hotmail.com> <000301c102e8$7b799b80$0d0ba8c0@joris2k.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2-current-20000114i
In-Reply-To: <000301c102e8$7b799b80$0d0ba8c0@joris2k.local>; from joris.dobbelsteen@mail.com on Mon, Jul 02, 2001 at 01:16:46PM +0200


I'd echo Joris' question as to why in the world you'd want to disable
chunking, but...

<shamless_plug>
http://www.mnot.net/cgi_buffer/

Buffers Perl, Python and PHP scripts; also can act as a wrapper for
arbitrary code. Intended to be useful for 1.0 content, and for
servers that don't chunk generated objects (most don't), but it
should be helpful here.
</shameless_plug>

I think there are also Apache modules, etc. that may do this, look
at http://modules.apache.org/



On Mon, Jul 02, 2001 at 01:16:46PM +0200, Joris Dobbelsteen wrote:
> Why not use it? It provided a way to keep the connection open.
> 
> You can try Tranfer-Encoding: identify
> see RFC2616 par. 14.41
> 
> There is also something with TE (par. 14.39).
> 
> Note that Apache will need to cache the response before transmitting it, to
> demitrade the length. I don't know wether they do or support that (probably
> they do). It requires only an enormous ammount of overhead on the server,
> not caused with chunked transfers. So why not use these, it's simple to
> build some support for that.
> 
> Before to forget, RFC2616 lists enough information in the sections with
> tranfer-codings and such....
> 
> 
> Have fun...
> 
> - Joris
> 
> >-----Original Message-----
> >From: manish kumar [mailto:manishksinghal@hotmail.com]
> >Sent: Monday, 02 July 2001 12:12
> >To: http-wg@cuckoo.hpl.hp.com
> >Subject: doubt regarding http 1.1
> >
> >
> >Hi
> >I am using http 1.1.I am making a persistent connection from
> >java client to
> >apache server.I am able to make it but I don't want to use
> >transfer encoding
> >as chunked(which is there by default).Is there any way I can
> >do it.Where I
> >need to change it.If you need some more detail please let me know.
> >
> >-Manish
> >_______________________________________________________________
> >__________
> >Get Your Private, Free E-mail from MSN Hotmail at
> http://www.hotmail.com.
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/

From manishksinghal@hotmail.com  Thu Jul  5 13:22:35 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id NAA29316 for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 13:22:34 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id NAA18091
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 13:22:34 +0100 (BST)
Received: from hotmail.com (f213.law11.hotmail.com [64.4.17.213])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id NAA22112
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 13:22:39 +0100 (BST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 5 Jul 2001 05:21:32 -0700
Received: from 202.9.179.16 by lw11fd.law11.hotmail.msn.com with HTTP;	Thu, 05 Jul 2001 12:21:32 GMT
X-Originating-IP: [202.9.179.16]
From: "manish kumar" <manishksinghal@hotmail.com>
To: mnot@mnot.net, joris.dobbelsteen@mail.com
Cc: http-wg@cuckoo.hpl.hp.com
Subject: Re: doubt regarding http 1.1
Date: Thu, 05 Jul 2001 12:21:32 -0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F213YTjr8cU6xfPTeip00015e0b@hotmail.com>
X-OriginalArrivalTime: 05 Jul 2001 12:21:32.0874 (UTC) FILETIME=[06DB4AA0:01C1054D]

Thanks for the response.It really helped in clearing some of the doubts.I am 
now having one more problem.I am using java socket and my server is apache.I 
am using http 1.1 ..I am having a problem with server closing the 
connection.Basically I want to have some way for server to send a message 
whenever its closing the connection.Is there any way it can be 
handled.Basically I want to differenciate between the case when server 
closes the existing socket(Only particular socket is not valid) and when 
server is down(No socket will work).


>From: Mark Nottingham <mnot@mnot.net>
>To: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
>CC: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
>Subject: Re: doubt regarding http 1.1
>Date: Mon, 2 Jul 2001 11:34:18 -0700
>
>
>I'd echo Joris' question as to why in the world you'd want to disable
>chunking, but...
>
><shamless_plug>
>http://www.mnot.net/cgi_buffer/
>
>Buffers Perl, Python and PHP scripts; also can act as a wrapper for
>arbitrary code. Intended to be useful for 1.0 content, and for
>servers that don't chunk generated objects (most don't), but it
>should be helpful here.
></shameless_plug>
>
>I think there are also Apache modules, etc. that may do this, look
>at http://modules.apache.org/
>
>
>
>On Mon, Jul 02, 2001 at 01:16:46PM +0200, Joris Dobbelsteen wrote:
> > Why not use it? It provided a way to keep the connection open.
> >
> > You can try Tranfer-Encoding: identify
> > see RFC2616 par. 14.41
> >
> > There is also something with TE (par. 14.39).
> >
> > Note that Apache will need to cache the response before transmitting it, 
>to
> > demitrade the length. I don't know wether they do or support that 
>(probably
> > they do). It requires only an enormous ammount of overhead on the 
>server,
> > not caused with chunked transfers. So why not use these, it's simple to
> > build some support for that.
> >
> > Before to forget, RFC2616 lists enough information in the sections with
> > tranfer-codings and such....
> >
> >
> > Have fun...
> >
> > - Joris
> >
> > >-----Original Message-----
> > >From: manish kumar [mailto:manishksinghal@hotmail.com]
> > >Sent: Monday, 02 July 2001 12:12
> > >To: http-wg@cuckoo.hpl.hp.com
> > >Subject: doubt regarding http 1.1
> > >
> > >
> > >Hi
> > >I am using http 1.1.I am making a persistent connection from
> > >java client to
> > >apache server.I am able to make it but I don't want to use
> > >transfer encoding
> > >as chunked(which is there by default).Is there any way I can
> > >do it.Where I
> > >need to change it.If you need some more detail please let me know.
> > >
> > >-Manish
> > >_______________________________________________________________
> > >__________
> > >Get Your Private, Free E-mail from MSN Hotmail at
> > http://www.hotmail.com.
> >
> >
>
>--
>Mark Nottingham
>http://www.mnot.net/
>

From manishksinghal@hotmail.com  Thu Jul  5 14:26:35 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id OAA01097 for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 14:26:35 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id OAA20738
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 14:26:34 +0100 (BST)
Received: from hotmail.com (f89.law11.hotmail.com [64.4.17.89])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id OAA25447
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 14:26:40 +0100 (BST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 5 Jul 2001 06:25:37 -0700
Received: from 202.9.179.16 by lw11fd.law11.hotmail.msn.com with HTTP;	Thu, 05 Jul 2001 13:25:37 GMT
X-Originating-IP: [202.9.179.16]
From: "manish kumar" <manishksinghal@hotmail.com>
To: http-wg@cuckoo.hpl.hp.com
Subject: problem with chunked encoding in http1.1
Date: Thu, 05 Jul 2001 13:25:37 -0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F89bi5REE8cQnrA2pC000010f74@hotmail.com>
X-OriginalArrivalTime: 05 Jul 2001 13:25:37.0750 (UTC) FILETIME=[FA94CF60:01C10555]

Hi
I am using http 1.1..My client side code is in java and server side is 
apache server.I am sending back response in xml format.My problem is now I 
am using transfer chunked encoding and having persistent connection. I don't 
know how to handle the chunked response.How we should handle different chunk 
of response like what will be the delimiter for one chunk and all this.No 
where on net I could find the real time example. Can somebody explain me how 
we do handle it.It will be really nice if somebody can send me the example 
chunk response which will have more then one chunk of response.I tried with 
my code but It always come in one chunk.I tried for larger response also but 
it never comes in more then one chunk.Is it being handled internally and we 
will always get one chunk only.
I badly need to know it.Somebody please help me with it.

TIA
-Manish
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

From njyoder@hotmail.com  Thu Jul  5 18:37:34 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id SAA03915 for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 18:37:34 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA00155
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 18:37:33 +0100 (BST)
Received: from hotmail.com (oe66.law7.hotmail.com [216.33.236.205])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id SAA06481
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 18:37:39 +0100 (BST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 5 Jul 2001 10:36:36 -0700
X-Originating-IP: [141.156.128.204]
From: "Nathan J. Yoder" <njyoder@hotmail.com>
To: <http-wg@cuckoo.hpl.hp.com>
References: <F89bi5REE8cQnrA2pC000010f74@hotmail.com>
Subject: Re: problem with chunked encoding in http1.1
Date: Thu, 5 Jul 2001 13:37:03 -0400
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE6681TbdkSmLAztxc100004c36@hotmail.com>
X-OriginalArrivalTime: 05 Jul 2001 17:36:36.0767 (UTC) FILETIME=[0A7472F0:01C10579]

My problem is now I
> am using transfer chunked encoding and having persistent connection. I
don't
> know how to handle the chunked response.How we should handle different
chunk
> of response like what will be the delimiter for one chunk and all this.No
> where on net I could find the real time example. Can somebody explain me
how
> we do handle it.It will be really nice if somebody can send me the example
> chunk response which will have more then one chunk of response.

Why not just connect to a server, send a request, and record the response in
a file?  This will give an example from a real web server (I would include
an example in this message, but a multi-chunk message would be too large).
Also, have you read the section of the HTTP/1.1 RFC on chunked transfer
encoding?  It's basically just a hex number (chunk length), newline,
content, another hex number (another chunk length), another newline,
content, then a 0 after the last chunk.  There are optional headers that may
be in there too, so check the RFC to get the full details and some
imlementations like to add superfluous characters (spaces) after the chunk
length and before the newline.

Also, as a response to earlier messages as to why to avoid chunked transfer
encoding--it's simple, chunked transfer encoding is needlessly complicated,
and is not even needed for persitent connections.  HTTP/1.0 supports
persistent connections with the "Connection" field set at "Keep-Alive" and
by using the "Content-Length" field to specify the file boundry.

From njyoder@hotmail.com  Thu Jul  5 18:49:08 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id SAA05385 for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 18:49:08 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA00728
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 18:49:07 +0100 (BST)
Received: from hotmail.com (oe67.law7.hotmail.com [216.33.236.206])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id SAA07146
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 18:49:13 +0100 (BST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 5 Jul 2001 10:48:10 -0700
X-Originating-IP: [141.156.128.204]
From: "Nathan J. Yoder" <njyoder@hotmail.com>
To: <http-wg@cuckoo.hpl.hp.com>
Subject: re: problem with chunked encoding in http1.1
Date: Thu, 5 Jul 2001 13:48:39 -0400
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <OE67ShcrbisBQHi6Nlw00004d53@hotmail.com>
X-OriginalArrivalTime: 05 Jul 2001 17:48:10.0610 (UTC) FILETIME=[A8047D20:01C1057A]

Ignore the second part of the last message, I didn't read the full response
in one of the e-mails.  That's right, chunked transfer enocoding is good for
messages of indeterminate length (like CGI generated responses), else it
would require caching the message in memory before sending (to determine the
length).

From mcmanus@appliedtheory.com  Thu Jul  5 19:13:50 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id TAA07162 for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 19:13:50 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id TAA01532
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 19:13:49 +0100 (BST)
Received: from justice.appliedtheory.com (ip-216-73-149-66.vantas.net [216.73.149.66])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id TAA08106
	for <http-wg@cuckoo.hpl.hp.com>; Thu, 5 Jul 2001 19:13:53 +0100 (BST)
Received: (from mcmanus@localhost)
	by justice.appliedtheory.com (8.11.2/8.11.2) id f65I4Q732207;
	Thu, 5 Jul 2001 14:04:26 -0400
Date: Thu, 5 Jul 2001 14:04:26 -0400
From: Patrick McManus <mcmanus@appliedtheory.com>
To: "Nathan J. Yoder" <njyoder@hotmail.com>
Cc: http-wg@cuckoo.hpl.hp.com
Subject: Re: problem with chunked encoding in http1.1
Message-ID: <20010705140426.A32189@AppliedTheory.com>
Reply-To: mcmanus@appliedtheory.com
References: <OE67ShcrbisBQHi6Nlw00004d53@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <OE67ShcrbisBQHi6Nlw00004d53@hotmail.com>; from njyoder@hotmail.com on Thu, Jul 05, 2001 at 01:48:39PM -0400

chunked is also required on any message that has any transfer-encoding
other than chunked or identity (e.g. gzip). This removes ambiguity of
whether content-length refers to the encoded or unencoded
entity. 

-P


[Nathan J. Yoder: Thu, Jul 05, 2001 at 01:48:39PM -0400]
> Ignore the second part of the last message, I didn't read the full response
> in one of the e-mails.  That's right, chunked transfer enocoding is good for
> messages of indeterminate length (like CGI generated responses), else it
> would require caching the message in memory before sending (to determine the
> length).
> 

From joris.dobbelsteen@mail.com  Tue Jul 17 15:16:44 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id PAA01174 for <http-wg@cuckoo.hpl.hp.com>; Tue, 17 Jul 2001 15:16:43 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id PAA05963
	for <http-wg@cuckoo.hpl.hp.com>; Tue, 17 Jul 2001 15:16:43 +0100 (BST)
Received: from rubellite.lion-access.net (rubellite.lion-access.net [212.19.217.4])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id PAA23380
	for <http-wg@cuckoo.hpl.hp.com>; Tue, 17 Jul 2001 15:16:49 +0100 (BST)
Received: from XTREME (1Cust45.tnt9.rtm1.nl.uu.net [213.116.112.45])
	by rubellite.lion-access.net (I-Lab) with SMTP
	id C7B3027E9; Tue, 17 Jul 2001 14:12:03 +0000 (GMT)
From: "Joris Dobbelsteen" <joris.dobbelsteen@mail.com>
To: "'Mark Nottingham'" <mnot@mnot.net>
Cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: RE: doubt regarding http 1.1
Date: Tue, 17 Jul 2001 16:18:39 +0200
Message-ID: <003701c10ecb$61eac3d0$0d0ba8c0@joris2k.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <20010702113415.B27968@mnot.net>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200

>-----Original Message-----
>From: Mark Nottingham [mailto:mnot@mnot.net]
>Sent: Monday, 02 July 2001 8:34
>To: Joris Dobbelsteen
>Cc: WWW WG (E-mail)
>Subject: Re: doubt regarding http 1.1
>
>
>
>I'd echo Joris' question as to why in the world you'd want to disable
>chunking, but...
>
><shamless_plug>
>http://www.mnot.net/cgi_buffer/
>
>Buffers Perl, Python and PHP scripts; also can act as a wrapper for
>arbitrary code. Intended to be useful for 1.0 content, and for

HTTP/1.0 doesn't support chunking, nor persistent connections (yes, there
are some extensions, but the origional spec doesn't support it). This way,
ending a response is done by closing the connection.

>servers that don't chunk generated objects (most don't), but it
>should be helpful here.
></shameless_plug>
>
>I think there are also Apache modules, etc. that may do this, look
>at http://modules.apache.org/
>
>
>
>On Mon, Jul 02, 2001 at 01:16:46PM +0200, Joris Dobbelsteen wrote:
>> Why not use it? It provided a way to keep the connection open.
>>
>> You can try Tranfer-Encoding: identify
>> see RFC2616 par. 14.41
>>
>> There is also something with TE (par. 14.39).
>>
>> Note that Apache will need to cache the response before
>transmitting it, to
>> demitrade the length. I don't know wether they do or support
>that (probably
>> they do). It requires only an enormous ammount of overhead
>on the server,
>> not caused with chunked transfers. So why not use these,
>it's simple to
>> build some support for that.
>>
>> Before to forget, RFC2616 lists enough information in the
>sections with
>> tranfer-codings and such....
>>
>>
>> Have fun...
>>
>> - Joris
>>
>> >-----Original Message-----
>> >From: manish kumar [mailto:manishksinghal@hotmail.com]
>> >Sent: Monday, 02 July 2001 12:12
>> >To: http-wg@cuckoo.hpl.hp.com
>> >Subject: doubt regarding http 1.1
>> >
>> >
>> >Hi
>> >I am using http 1.1.I am making a persistent connection from
>> >java client to
>> >apache server.I am able to make it but I don't want to use
>> >transfer encoding
>> >as chunked(which is there by default).Is there any way I can
>> >do it.Where I
>> >need to change it.If you need some more detail please let me know.
>> >
>> >-Manish
>> >_______________________________________________________________
>> >__________
>> >Get Your Private, Free E-mail from MSN Hotmail at
>> http://www.hotmail.com.
>>
>>
>
>--
>Mark Nottingham
>http://www.mnot.net/
>
>

From joris.dobbelsteen@mail.com  Tue Jul 17 15:16:44 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id PAA01176 for <http-wg@cuckoo.hpl.hp.com>; Tue, 17 Jul 2001 15:16:44 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id PAA05964
	for <http-wg@cuckoo.hpl.hp.com>; Tue, 17 Jul 2001 15:16:43 +0100 (BST)
Received: from rubellite.lion-access.net (rubellite.lion-access.net [212.19.217.4])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id PAA23378
	for <http-wg@cuckoo.hpl.hp.com>; Tue, 17 Jul 2001 15:16:48 +0100 (BST)
Received: from XTREME (1Cust45.tnt9.rtm1.nl.uu.net [213.116.112.45])
	by rubellite.lion-access.net (I-Lab) with SMTP
	id 9938A27DD; Tue, 17 Jul 2001 14:11:59 +0000 (GMT)
From: "Joris Dobbelsteen" <joris.dobbelsteen@mail.com>
To: "'manish kumar'" <manishksinghal@hotmail.com>
Cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: RE: doubt regarding http 1.1
Date: Tue, 17 Jul 2001 16:18:37 +0200
Message-ID: <003601c10ecb$5f646710$0d0ba8c0@joris2k.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <F213YTjr8cU6xfPTeip00015e0b@hotmail.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200

>-----Original Message-----
>From: manish kumar [mailto:manishksinghal@hotmail.com]
>Sent: Thursday, 05 July 2001 2:22
>To: mnot@mnot.net; joris.dobbelsteen@mail.com
>Cc: http-wg@cuckoo.hpl.hp.com
>Subject: Re: doubt regarding http 1.1
>
>
>Thanks for the response.It really helped in clearing some of
>the doubts.I am
>now having one more problem.I am using java socket and my
>server is apache.I
>am using http 1.1 ..I am having a problem with server closing the
>connection.Basically I want to have some way for server to
>send a message
>whenever its closing the connection.Is there any way it can be
>handled.Basically I want to differenciate between the case when server
>closes the existing socket(Only particular socket is not
>valid) and when
>server is down(No socket will work).

Servers (most/some/dunno) will send the "Connection: Close" header when they
close the connection directly after a response.
After some time (idle time-out) servers close connections in order to save
bandwidth and clean-up connection that are no longer used, you probably
don't need them anyway.

HTTP/1.x has no method to inform about closing a inactive connection. You
will just notice the connection has been closed.
If the server is down, you can't connect to the server...


- Joris

>
>
>>From: Mark Nottingham <mnot@mnot.net>
>>To: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
>>CC: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
>>Subject: Re: doubt regarding http 1.1
>>Date: Mon, 2 Jul 2001 11:34:18 -0700
>>
>>
>>I'd echo Joris' question as to why in the world you'd want to disable
>>chunking, but...
>>
>><shamless_plug>
>>http://www.mnot.net/cgi_buffer/
>>
>>Buffers Perl, Python and PHP scripts; also can act as a wrapper for
>>arbitrary code. Intended to be useful for 1.0 content, and for
>>servers that don't chunk generated objects (most don't), but it
>>should be helpful here.
>></shameless_plug>
>>
>>I think there are also Apache modules, etc. that may do this, look
>>at http://modules.apache.org/
>>
>>
>>
>>On Mon, Jul 02, 2001 at 01:16:46PM +0200, Joris Dobbelsteen wrote:
>> > Why not use it? It provided a way to keep the connection open.
>> >
>> > You can try Tranfer-Encoding: identify
>> > see RFC2616 par. 14.41
>> >
>> > There is also something with TE (par. 14.39).
>> >
>> > Note that Apache will need to cache the response before
>transmitting it,
>>to
>> > demitrade the length. I don't know wether they do or support that
>>(probably
>> > they do). It requires only an enormous ammount of overhead on the
>>server,
>> > not caused with chunked transfers. So why not use these,
>it's simple to
>> > build some support for that.
>> >
>> > Before to forget, RFC2616 lists enough information in the
>sections with
>> > tranfer-codings and such....
>> >
>> >
>> > Have fun...
>> >
>> > - Joris
>> >
>> > >-----Original Message-----
>> > >From: manish kumar [mailto:manishksinghal@hotmail.com]
>> > >Sent: Monday, 02 July 2001 12:12
>> > >To: http-wg@cuckoo.hpl.hp.com
>> > >Subject: doubt regarding http 1.1
>> > >
>> > >
>> > >Hi
>> > >I am using http 1.1.I am making a persistent connection from
>> > >java client to
>> > >apache server.I am able to make it but I don't want to use
>> > >transfer encoding
>> > >as chunked(which is there by default).Is there any way I can
>> > >do it.Where I
>> > >need to change it.If you need some more detail please let me know.
>> > >
>> > >-Manish
>> > >_______________________________________________________________
>> > >__________
>> > >Get Your Private, Free E-mail from MSN Hotmail at
>> > http://www.hotmail.com.
>> >
>> >
>>
>>--
>>Mark Nottingham
>>http://www.mnot.net/
>>
>
>_______________________________________________________________
>__________
>Get Your Private, Free E-mail from MSN Hotmail at
http://www.hotmail.com.

From tapan_divekar@hotmail.com  Sun Jul 29 08:36:19 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id IAA23001 for <http-wg@cuckoo.hpl.hp.com>; Sun, 29 Jul 2001 08:36:19 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id IAA04724
	for <http-wg@cuckoo.hpl.hp.com>; Sun, 29 Jul 2001 08:36:19 +0100 (BST)
Received: from hotmail.com (f223.law8.hotmail.com [216.33.241.223])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id IAA12720
	for <http-wg@cuckoo.hpl.hp.com>; Sun, 29 Jul 2001 08:36:25 +0100 (BST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sun, 29 Jul 2001 00:35:14 -0700
Received: from 128.227.170.190 by lw8fd.law8.hotmail.msn.com with HTTP;	Sun, 29 Jul 2001 07:35:14 GMT
X-Originating-IP: [128.227.170.190]
From: "Tapan Divekar" <tapan_divekar@hotmail.com>
To: http-wg@cuckoo.hpl.hp.com
Subject: server side programming?
Date: Sun, 29 Jul 2001 07:35:14 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F223bLYluLCTaogxLDp00008f8c@hotmail.com>
X-OriginalArrivalTime: 29 Jul 2001 07:35:14.0799 (UTC) FILETIME=[01D70FF0:01C11801]

Hi ,
I ve been trying to write  a small HTTP Server app. which shall take in 
requests from browser and send some results back (in Java).
serverSocket is created on port 4444.
Following is a snippet from the code --


Socket clientSocket = null;

        try {
            clientSocket = serverSocket.accept();
        } catch (IOException e) {
            System.err.println("Accept failed.");
            System.exit(1);
        }

			PrintWriter os = new PrintWriter(clientSocket.getOutputStream(),true);
//DataInputStream is = new DataInputStream(clientSocket.getInputStream());
			BufferedReader is =new BufferedReader(new 
InputStreamReader(clientSocket.getInputStream()));
String fromServer=new String();
while ((fromServer = is.readLine()) != null) {

    System.out.println("Server: " + fromServer);


	os.println("<html>hello lhlg  </html>");
	System.out.println("Server:  before flush");

	 os.flush();
		System.out.println("Server: after flush");
}
}

Even though server receives some data it is unable to post data back.
Any ideas where I might be going wrong?
Thanks
Tapan

From mnot@1-132.mnot.net  Tue Jul 17 16:04:54 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id QAA04633 for <http-wg@cuckoo.hpl.hp.com>; Tue, 17 Jul 2001 16:04:53 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA08468
	for <http-wg@cuckoo.hpl.hp.com>; Tue, 17 Jul 2001 16:04:53 +0100 (BST)
Received: from 1-132.mnot.net (adsl-64-170-196-242.dsl.snfc21.pacbell.net [64.170.196.242])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id QAA25968
	for <http-wg@cuckoo.hpl.hp.com>; Tue, 17 Jul 2001 16:04:58 +0100 (BST)
Received: by 1-132.mnot.net (Postfix, from userid 500)
	id B483845E; Tue, 17 Jul 2001 08:01:38 -0700 (PDT)
Date: Tue, 17 Jul 2001 08:01:38 -0700
From: Mark Nottingham <mnot@mnot.net>
To: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
Cc: "WWW WG (E-mail)" <http-wg@cuckoo.hpl.hp.com>
Subject: Re: doubt regarding http 1.1
Message-ID: <20010717080132.E1211@mnot.net>
References: <20010702113415.B27968@mnot.net> <003701c10ecb$61eac3d0$0d0ba8c0@joris2k.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <003701c10ecb$61eac3d0$0d0ba8c0@joris2k.local>; from joris.dobbelsteen@mail.com on Tue, Jul 17, 2001 at 04:18:39PM +0200


Yes, they're extensions, but all widely-used 1.0 implementations use
them, to the best of my knowledge. More to the point, many "1.1"
server implementations won't chunk some content, depending on how the
entity is generated, leading them to close the connection.
Conversely, if the generation engine supplies them with a
Content-Length header, they not only will not close the connection,
they won't chunk it, giving the desired effect.




On Tue, Jul 17, 2001 at 04:18:39PM +0200, Joris Dobbelsteen wrote:
> >-----Original Message-----
> >From: Mark Nottingham [mailto:mnot@mnot.net]
> >Sent: Monday, 02 July 2001 8:34
> >To: Joris Dobbelsteen
> >Cc: WWW WG (E-mail)
> >Subject: Re: doubt regarding http 1.1
> >
> >
> >
> >I'd echo Joris' question as to why in the world you'd want to disable
> >chunking, but...
> >
> ><shamless_plug>
> >http://www.mnot.net/cgi_buffer/
> >
> >Buffers Perl, Python and PHP scripts; also can act as a wrapper for
> >arbitrary code. Intended to be useful for 1.0 content, and for
> 
> HTTP/1.0 doesn't support chunking, nor persistent connections (yes, there
> are some extensions, but the origional spec doesn't support it). This way,
> ending a response is done by closing the connection.
> 
> >servers that don't chunk generated objects (most don't), but it
> >should be helpful here.
> ></shameless_plug>
> >
> >I think there are also Apache modules, etc. that may do this, look
> >at http://modules.apache.org/
> >
> >
> >
> >On Mon, Jul 02, 2001 at 01:16:46PM +0200, Joris Dobbelsteen wrote:
> >> Why not use it? It provided a way to keep the connection open.
> >>
> >> You can try Tranfer-Encoding: identify
> >> see RFC2616 par. 14.41
> >>
> >> There is also something with TE (par. 14.39).
> >>
> >> Note that Apache will need to cache the response before
> >transmitting it, to
> >> demitrade the length. I don't know wether they do or support
> >that (probably
> >> they do). It requires only an enormous ammount of overhead
> >on the server,
> >> not caused with chunked transfers. So why not use these,
> >it's simple to
> >> build some support for that.
> >>
> >> Before to forget, RFC2616 lists enough information in the
> >sections with
> >> tranfer-codings and such....
> >>
> >>
> >> Have fun...
> >>
> >> - Joris
> >>
> >> >-----Original Message-----
> >> >From: manish kumar [mailto:manishksinghal@hotmail.com]
> >> >Sent: Monday, 02 July 2001 12:12
> >> >To: http-wg@cuckoo.hpl.hp.com
> >> >Subject: doubt regarding http 1.1
> >> >
> >> >
> >> >Hi
> >> >I am using http 1.1.I am making a persistent connection from
> >> >java client to
> >> >apache server.I am able to make it but I don't want to use
> >> >transfer encoding
> >> >as chunked(which is there by default).Is there any way I can
> >> >do it.Where I
> >> >need to change it.If you need some more detail please let me know.
> >> >
> >> >-Manish
> >> >_______________________________________________________________
> >> >__________
> >> >Get Your Private, Free E-mail from MSN Hotmail at
> >> http://www.hotmail.com.
> >>
> >>
> >
> >--
> >Mark Nottingham
> >http://www.mnot.net/
> >
> >
> 

-- 
Mark Nottingham
http://www.mnot.net/

From LMM@acm.org  Tue Jul 31 03:02:14 2001
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by cuckoo.hpl.hp.com with ESMTP (8.7.6/8.7.3 TIS 5.0) id DAA12027 for <http-wg@cuckoo.hpl.hp.com>; Tue, 31 Jul 2001 03:02:13 +0100 (BST)
Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.144.59.8])
	by otter.hpl.hp.com (8.9.3 (PHNE_22672)/HP-Labs Bristol Internal Mail Hub) with ESMTP id DAA09140
	for <http-wg@hplb.hpl.hp.com>; Tue, 31 Jul 2001 03:01:57 +0100 (BST)
Received: from adobe.com ([192.150.11.2])
	by hplb.hpl.hp.com (8.9.3 (PHNE_22672)/ HPLabs Bristol Relay) with ESMTP id DAA04287
	for <http-wg@hplb.hpl.hp.com>; Tue, 31 Jul 2001 03:02:04 +0100 (BST)
Received: from inner-relay-2.corp.adobe.com ([153.32.1.52])
	by adobe.com (1.0.0/8.11.4) with ESMTP id f6V1xIt20017
	for <http-wg@hplb.hpl.hp.com>; Mon, 30 Jul 2001 18:59:18 -0700 (PDT)
Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192])
	by inner-relay-2.corp.adobe.com (8.11.4/8.11.4) with ESMTP id f6V1xGb27125
	for <http-wg@hplb.hpl.hp.com>; Mon, 30 Jul 2001 18:59:16 -0700 (PDT)
Received: from larrypad ([130.248.190.171]) by
          mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul
          11 2001 16:32:57) with SMTP id GHBEUZ00.4LG; Mon, 30 Jul 2001
          18:59:23 -0700 
From: "Larry Masinter" <LMM@acm.org>
To: "HTTP Working Group" <http-wg@hplb.hpl.hp.com>
Cc: <csbruce@cubewerx.com>,
        "Jeff de La Beaujardiere" <delabeau@iniki.gsfc.nasa.gov>
Subject: Errata: HTTP URL abs_path should include query
Date: Mon, 30 Jul 2001 18:58:37 -0700
Message-ID: <NDBBKEBDLFENBJCGFOIJGENFFFAA.LMM@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <200107271922.PAA53150@iniki.gsfc.nasa.gov>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

I believe there was a glitch in RFC 2616; it defines
 
    Request-URI    = "*" | absoluteURI | abs_path

where it gets abs_path by reference to RFC 2396; however, the
abs_path in RFC 2396 doesn't include a possible query part:

      hier_part     = ( net_path | abs_path ) [ "?" query ]
      net_path      = "//" authority [ abs_path ]
      abs_path      = "/"  path_segments


I think what happened was that we updated the URI reference
late in the game, but between the RFC 1808 URL definition
and the RFC 2616 definition, the BNF changed and defined
abs_path differently.

To fix this, the simplest thing to do is to patch


    Request-URI   = "*" | absoluteURI | abs_path [ "?" query ]


In retrospect, changing the BNF in RFC 2396 (Generic URI syntax)
was a big mistake; it's led to several problems of this form.

Thanks to Jeff de La Beaujardiere and Craig Bruce for reporting
this.