Changeset 2603


Ignore:
Timestamp:
Jan 28, 2014, 6:01:00 PM (6 years ago)
Author:
fielding@…
Message:

(editorial) move factual statement about Upgrade up to the first paragraph to avoid repeating the MAY requirement on servers; see #531

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2602 r2603  
    23062306            <p id="rfc.section.6.7.p.1">The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol
    23072307               on the same connection. A client <em class="bcp14">MAY</em> send a list of protocols in the Upgrade header field of a request to invite the server to switch to one or more of those protocols,
    2308                in order of descending preference, before sending the final response. A server <em class="bcp14">MAY</em> ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection.
     2308               in order of descending preference, before sending the final response. A server <em class="bcp14">MAY</em> ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection. Upgrade cannot
     2309               be used to insist on a protocol change.
    23092310            </p>
    23102311            <div id="rfc.figure.u.62"></div><pre class="inline"><span id="rfc.iref.g.97"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a>          = 1#<a href="#header.upgrade" class="smpl">protocol</a>
     
    23282329Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    23292330
    2330 </pre><p id="rfc.section.6.7.p.7">Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities
    2331                and nature of the application-level communication after the protocol change is entirely dependent upon the new protocol(s)
    2332                chosen. However, immediately after sending the 101 response, the server is expected to continue responding to the original
    2333                request as if it had received its equivalent within the new protocol (i.e., the server still has an outstanding request to
    2334                satisfy after the protocol has been changed, and is expected to do so without requiring the request to be repeated).
     2331</pre><p id="rfc.section.6.7.p.7">The capabilities and nature of the application-level communication after the protocol change is entirely dependent upon the
     2332               new protocol(s) chosen. However, immediately after sending the 101 response, the server is expected to continue responding
     2333               to the original request as if it had received its equivalent within the new protocol (i.e., the server still has an outstanding
     2334               request to satisfy after the protocol has been changed, and is expected to do so without requiring the request to be repeated).
    23352335            </p>
    23362336            <p id="rfc.section.6.7.p.8">For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, it first
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2602 r2603  
    32333233   the final response. A server &MAY; ignore a received Upgrade header field
    32343234   if it wishes to continue using the current protocol on that connection.
     3235   Upgrade cannot be used to insist on a protocol change.
    32353236</t>
    32363237<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Upgrade"/>
     
    32723273</artwork></figure>
    32733274<t>
    3274    Upgrade cannot be used to insist on a protocol change; its acceptance and
    3275    use by the server is optional. The capabilities and nature of the
     3275   The capabilities and nature of the
    32763276   application-level communication after the protocol change is entirely
    32773277   dependent upon the new protocol(s) chosen. However, immediately after
Note: See TracChangeset for help on using the changeset viewer.