IPP Mail Archive: Re: IPP> PRO> : HTTP vs. HTTP-lite; HTTP headers?

Re: IPP> PRO> : HTTP vs. HTTP-lite; HTTP headers?

Robert Herriot (robert.herriot@Eng.Sun.COM)
Tue, 25 Aug 1998 14:11:41 -0700

I wrote this language. My reasoning was that the sender of the request or response must include a header "Cache-control: no-cache" in order to prevent caching from occurring in various proxy servers. But an origin server (containing IPP support) should not support Cache-control because cache-control is intended for proxy servers.

Bob Herriot

At 07:56 AM 8/25/98 , Carl Kugler wrote:
># I doubt there is a golden document somewhere that specifies how the
>> # browsers exactly deal with the all caches and all flavors of proxy
>> # servers around.
>>
>> If a response includes
>> Cache-control: no-cache
>> then there should not be any difficulty with IPP and caching.
>> Print clients shouldn't need to say anything about caching, just print
>> servers, and the only thing servers need to say is about cache expiry
>> for information that shouldn't be cached.
>>
>> It more likely a feature that static information returned from
>> querying a printer about its configuration can be cached.
>>
>> Larry
>>
>>
>
>I'm having trouble understanding section 4. Encoding of Transport Layer, in PRO 6/30. If I understand the table in section 4.1, it says, for General-Header Cache-Control,
>
> - the client MUST send the header in a Request
> - the server SHOULD NOT support the header in a Request. It is not relevant to an IPP implementation.
> - the server MUST send the header in a Response
> - the client SHOULD NOT support the header in a Response. It is not relevant to an IPP implementation.
>
>What is the definition of "support" in this context? Why MUST we send a header which the receiver SHOULD NOT support? The same questions apply to the "Pragma" header.
>
> -Carl
>
>-----
>Original Message: http://www.findmail.com/list/ipp/?start=79
>Start a FREE email list at http://www.FindMail.com/
>