Standards Track A. Rao Netscap - RFC Editor

RFC 2326 Real Time Streaming Protocol April 1998A stale cache entry may not normally be returned by a cache (either aproxy cache or an user agent cache) unless it is first validated withthe origin server (or with an intermediate cache that has a freshcopy of the entity). See section 13 for further discussion of theexpiration model.The presence of an Expires field does not imply that the originalresource will change or cease to exist at, before, or after thattime.The format is an absolute date and time as defined by HTTP-date in[H3.3]; it MUST be in RFC1123-date format:Expires = "Expires" ":" HTTP-dateAn example of its use isExpires: Thu, 01 Dec 1994 16:00:00 GMTRTSP/1.0 clients and caches MUST treat other invalid date formats,especially including the value "0", as having occurred in the past(i.e., "already expired").To mark a response as "already expired," an origin server should usean Expires date that is equal to the Date header value. To mark aresponse as "never expires," an origin server should use an Expiresdate approximately one year from the time the response is sent.RTSP/1.0 servers should not send Expires dates more than one year inthe future.The presence of an Expires header field with a date value of sometime in the future on a media stream that otherwise would by defaultbe non-cacheable indicates that the media stream is cacheable, unlessindicated otherwise by a Cache-Control header field (Section 12.8).12.20 FromSee [H14.22].12.21 HostThis HTTP request header field is not needed for RTSP. It should besilently ignored if sent.12.22 If-MatchSee [H14.25].Schulzrinne, et. al. Standards Track [Page 51]