Ignore:
Timestamp:
Jul 24, 2010, 2:23:44 AM (9 years ago)
Author:
julian.reschke@…
Message:

Remove "Changes from RFC 2068" sections (see #220)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p5-range.xml

    r908 r911  
    598598   ranges), these are transmitted as a multipart message. The multipart
    599599   media type used for this purpose is "multipart/byteranges" as defined
    600    in <xref target="internet.media.type.multipart.byteranges"/>. See <xref target="changes.from.rfc.2068"/> for a compatibility issue.
     600   in <xref target="internet.media.type.multipart.byteranges"/>.
    601601</t>
    602602<t>
     
    13021302
    13031303<section title="Compatibility with Previous Versions" anchor="compatibility">
    1304 <section title="Changes from RFC 2068" anchor="changes.from.rfc.2068">
    1305 <t>
    1306    Transfer-coding and message lengths all interact in ways that
    1307    required fixing exactly when chunked encoding is used (to allow for
    1308    transfer encoding that may not be self delimiting); it was important
    1309    to straighten out exactly how message lengths are computed.
    1310    (<xref target="header.content-range"/>,
    1311    see also <xref target="Part1"/>)
    1312 </t>
    1313 <t>
    1314    There are situations where a server (especially a proxy) does not
    1315    know the full length of a response but is capable of serving a
    1316    byterange request. We therefore need a mechanism to allow byteranges
    1317    with a content-range not indicating the full length of the message.
    1318    (<xref target="header.content-range"/>)
    1319 </t>
    1320 <t>
    1321    Range request responses would become very verbose if all meta-data
    1322    were always returned; by allowing the server to only send needed
    1323    headers in a 206 response, this problem can be avoided.
    1324    (Section <xref target="status.206" format="counter"/>
    1325    and <xref target="header.if-range" format="counter"/>)
    1326 </t>
    1327 <t>
    1328    Fix problem with unsatisfiable range requests; there are two cases:
    1329    syntactic problems, and range doesn't exist in the document. The 416
    1330    status code was needed to resolve this ambiguity needed to indicate
    1331    an error for a byte range request that falls outside of the actual
    1332    contents of a document. (Section <xref target="status.416" format="counter"/>, <xref target="header.content-range" format="counter"/>)
    1333 </t>
    1334 </section>
    1335 
    13361304<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    13371305<t>
     
    15941562      "Clarify entity / representation / variant terminology"
    15951563    </t>
     1564    <t>
     1565      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
     1566      "Clarify entity / representation / variant terminology"
     1567    </t>
     1568    <t>
     1569      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
     1570      "consider removing the 'changes from 2068' sections"
     1571    </t>
    15961572  </list>
    15971573</t>
Note: See TracChangeset for help on using the changeset viewer.