Standards Track A. Rao Netscap - RFC Editor

More documents

Recommendations

Info

RFC 2326 Real Time Streaming Protocol April 199812.13 Content-LanguageSee [H14.13]12.14 Content-LengthThis field contains the length of the content of the method (i.e.after the double CRLF following the last header). Unlike HTTP, itMUST be included in all messages that carry content beyond the headerportion of the message. If it is missing, a default value of zero isassumed. It is interpreted according to [H14.14].12.15 Content-LocationSee [H14.15]12.16 Content-TypeSee [H14.18]. Note that the content types suitable for RTSP arelikely to be restricted in practice to presentation descriptions andparameter-value types.12.17 CSeqThe CSeq field specifies the sequence number for an RTSP requestresponsepair. This field MUST be present in all requests andresponses. For every RTSP request containing the given sequencenumber, there will be a corresponding response having the samenumber. Any retransmitted request must contain the same sequencenumber as the original (i.e. the sequence number is not incrementedfor retransmissions of the same request).12.18 DateSee [H14.19].12.19 ExpiresThe Expires entity-header field gives a date and time after which thedescription or media-stream should be considered stale. Theinterpretation depends on the method:DESCRIBE response:The Expires header indicates a date and time after which thedescription should be considered stale.Schulzrinne, et. al. Standards Track [Page 50]
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]
Page 2 and 3: RFC 2326 Real Time Streaming Protoc
Page 7: RFC 2326 Real Time Streaming Protoc
Page 92: RFC 2326 Real Time Streaming Protoc

Standards Track A. Rao Netscap - RFC Editor

Create successful ePaper yourself

Delete template?

Save as template?