Bala's papers on HTTP/1.1 compliance (fwd)

[Brian Behlendorf <br...@apache.org>]

This may have been covered when it came out, I'm not sure, but if anyone
wants to take a look....

	Brian

---------- Forwarded message ----------
Date: Thu, 27 Apr 2000 18:51:09 -0700
From: Larry Masinter <LM...@att.com>
To: Brian Behlendorf <br...@collab.net>
Cc: Balachander Krishnamurthy <ba...@research.att.com>
Subject: Bala's papers on HTTP/1.1 compliance

Brian,

We were talking about what Apache could do to help users with HTTP/1.1
compliance.
You were interested in the work I described, done by Bala Krishnamurthy and
friends,
to measure HTTP/1.1 compliance.

You might look at http://www.research.att.com/~bala/papers/ and, in
particular,
http://www.research.att.com/~bala/papers/procow-1.ps.gz (paper on HTTP/1.1
compliance).

Apparently some of the non-compliance came from user configuration, CGI or
whatever.

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

Re: Bala's papers on HTTP/1.1 compliance (fwd)

[Koen Holtman <Ko...@cern.ch>]

One data point: I read the paper procow-1.ps.gz soon after it came out. 
I went over my notes and there is nothing really alarming in there
Apache-wise. 

On the other hand, there are ways in which Apache can help users in being
more 1.1 compliant.  One thing I found in my old (early 1999) notes:
    
     Apache currently does not do anything special with
     ETag headers returned by CGI scripts, even if the scripts are
     invoked without content negotiation.  This means that if a
     dynamic content CGI scripts wants to be cache-friendly to 1.1
     caches, it will have to do its own If-Match and If-None-Match
     processing.  This is a pain, it should be done by Apache in
     ap_meets_conditions.  Fixing it is straightforward but it is
     also a CGI interface change.

I also seem to recall that if mod_expires is enabled, Expires: <date in
future> will be added even to some 'dynamic' responses (produced by other
modules) that should really be uncacheable as far as the other module is
concerned. This is less of a 1.1 compliance issue as it is one in which a
certain configuration setting has compliant but unintentional side
effects. 

There is probably more stuff like this.  The thought of it keeps nagging
me, but I find that I never have the spare time to start doing something
about it. 

Koen.


On Sun, 7 May 2000, Brian Behlendorf wrote:

> 
> This may have been covered when it came out, I'm not sure, but if anyone
> wants to take a look....
> 
> 	Brian
> 
> ---------- Forwarded message ----------
> Date: Thu, 27 Apr 2000 18:51:09 -0700
> From: Larry Masinter <LM...@att.com>
> To: Brian Behlendorf <br...@collab.net>
> Cc: Balachander Krishnamurthy <ba...@research.att.com>
> Subject: Bala's papers on HTTP/1.1 compliance
> 
> Brian,
> 
> We were talking about what Apache could do to help users with HTTP/1.1
> compliance.
> You were interested in the work I described, done by Bala Krishnamurthy and
> friends,
> to measure HTTP/1.1 compliance.
> 
> You might look at http://www.research.att.com/~bala/papers/ and, in
> particular,
> http://www.research.att.com/~bala/papers/procow-1.ps.gz (paper on HTTP/1.1
> compliance).
> 
> Apparently some of the non-compliance came from user configuration, CGI or
> whatever.
> 
> Larry
> --
> http://larry.masinter.net
> 
> 
> 
>