[DOC] undocumented ContentDigest directive

[Lars Eilebrecht <La...@unix-ag.org>]

Hi,

the ContentDigest directive is available since the first versions
of Apache, but still undocumented.
Attached is a patch to add it to the manual.


ciao...
--
Lars Eilebrecht                        - Perl: The only language you can
sfx@unix-ag.org                                 uuencode and not notice.
http://www.si.unix-ag.org/~sfx/

Re: [DOC] undocumented ContentDigest directive

[Lars Eilebrecht <La...@unix-ag.org>]

According to Alexei Kosut:

>  No, only since 1.1 or so. And -1 on adding it to the manual. It's an
>  undocumented feature. It was a bit proof-of-content code I added to
>  Apache, and was never designed to be used in a real web server. I forget
>  why - there's nothing insecure or anything about it - but I think it had
>  to do with performance (or lack thereof).

Hmm... IdentityCheck has also a bad influence on server performance...
and I suspect that there are many servers out there who have it
enabled.

>  Also, I am aware of 0 web browsers that make use of it.

If no server produces Content-MD5 headers, no browser (or proxy) will
make use of it. ,-)

[...]
>  So there's really no use for it.

Content-MD5 headers are an optional part of HTTP/1.1, Apache implements
it and therefore it should be documented (or removed), IMHO.

BTW, most of the servers I maintain have ContentDigest enabled...


ciao...
--
Lars Eilebrecht                       - It is impossible to make anything
sfx@unix-ag.org                  - foolproof, because fools are so ingenious.
http://www.si.unix-ag.org/~sfx/

Re: [DOC] undocumented ContentDigest directive

[Dean Gaudet <dg...@arctic.org>]

It's pretty easy to make this efficient if you were to write a module
which cached the results of the digest.  Use something like msql, or
anything that can have multiple concurrent writers.

Dean

On Sun, 24 Aug 1997, Alexei Kosut wrote:

> On Sun, 24 Aug 1997, Lars Eilebrecht wrote:
> 
> > the ContentDigest directive is available since the first versions
> > of Apache, but still undocumented.
> > Attached is a patch to add it to the manual.
> 
> No, only since 1.1 or so. And -1 on adding it to the manual. It's an
> undocumented feature. It was a bit proof-of-content code I added to
> Apache, and was never designed to be used in a real web server. I forget
> why - there's nothing insecure or anything about it - but I think it had to
> do with performance (or lack thereof). Also, I am aware of 0 web browsers
> that make use of it.
> 
> It's only possible use is to make sure a message wasn't truncated in
> transit (since if the message can be changed, so can the hash, and TCP
> has its own mechanisms to prevent data from being corrupted, so that's
> not a concern), but Apache only applies it to files served by the core,
> which all have Content-Length statements anyhow. And HTTP/1.1 provides
> chunking to all other files, anyway.
> 
> So there's really no use for it.
> 
> -- Alexei Kosut <ak...@organic.com>
> 
> 

Re: [DOC] undocumented ContentDigest directive

[Alexei Kosut <ak...@organic.com>]

On Sun, 24 Aug 1997, Lars Eilebrecht wrote:

> the ContentDigest directive is available since the first versions
> of Apache, but still undocumented.
> Attached is a patch to add it to the manual.

No, only since 1.1 or so. And -1 on adding it to the manual. It's an
undocumented feature. It was a bit proof-of-content code I added to
Apache, and was never designed to be used in a real web server. I forget
why - there's nothing insecure or anything about it - but I think it had to
do with performance (or lack thereof). Also, I am aware of 0 web browsers
that make use of it.

It's only possible use is to make sure a message wasn't truncated in
transit (since if the message can be changed, so can the hash, and TCP
has its own mechanisms to prevent data from being corrupted, so that's
not a concern), but Apache only applies it to files served by the core,
which all have Content-Length statements anyhow. And HTTP/1.1 provides
chunking to all other files, anyway.

So there's really no use for it.

-- Alexei Kosut <ak...@organic.com>