That's true, but it leaves out the following:
1) Most servers won't care about that data, so it is sending
unnecessary information.
2) The last action of a cache does not involve a request to
the origin server, so there is no request on which you
can bundle the last set of information.
>Roy Fielding <[email protected]> writes:
>> Like Andrew mentioned, this is best done by passing a URL
>> to the origin server that tells it where it may retrieve a
>> sanitized summary of the data.
>
>Actually, I believe he was suggesting a URL in the *other*
>direction.
Oh, well that would work as well:
Server-Log-Forward: http://site/blah/blah
and then the transfer action is just a POST of a defined media type.
> Allowing report retrieval from the proxy by the origin
>server would either be less secure, or even more complex and
>unreliable.
Not less secure (in that case it just wouldn't be available).
>> In regard to the proxy passing logfile info to servers, I
>> do hope people discussing these issues have looked at the
>> Security section of the HTTP spec.
>
>Yes, to be more careful, the log info should rather be:
>
> *.domain [request-id] timestamp [referer]
>
>where "*.domain" is the hostname sanitized with wildcards as
>needed; the optional Referer is null when it would conflict with
>security; and the presence or absence of the Request-ID is
>controlled at the client (is there any reason for further control at
>the proxy?).
Keep in mind that the proxy may know a lot more about an individual
client than is available via HTTP. For example, the proxy may have
authenticated the user and can generate its own anonymous id. So, I
would say:
timestamp HT domain HT [anonymous-id] HT [referer]
would be just fine, with domain being defined by the proxy.
Can this discussion be moved out of HTTP-WG now? I would not
want to attempt standardization until it can be tested on at least
one implemention, and this discussion is drowning out the real work
that we need to accomplish RIGHT NOW on the 1.0 and 1.1 specs.
....Roy T. Fielding Department of ICS, University of California, Irvine USA
Visiting Scholar, MIT/LCS + World-Wide Web Consortium
([email protected]) ([email protected])