* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 2101


Ignore:
Timestamp:
2013-01-08 10:31:02 (18 months ago)
Author:
julian.reschke@gmx.de
Message:

avoid a MUST in a test following "For example" (see http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0013.html)

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

Legend:

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

    r2086 r2101  
    449449  }  
    450450  @bottom-center { 
    451        content: "Expires July 9, 2013";  
     451       content: "Expires July 12, 2013";  
    452452  }  
    453453  @bottom-right { 
     
    491491      <meta name="dct.creator" content="Reschke, J. F."> 
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-01-05"> 
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-01-08"> 
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 
     
    520520            <tr> 
    521521               <td class="left">Intended status: Standards Track</td> 
    522                <td class="right">January 5, 2013</td> 
     522               <td class="right">January 8, 2013</td> 
    523523            </tr> 
    524524            <tr> 
    525                <td class="left">Expires: July 9, 2013</td> 
     525               <td class="left">Expires: July 12, 2013</td> 
    526526               <td class="right"></td> 
    527527            </tr> 
     
    551551         in progress”. 
    552552      </p> 
    553       <p>This Internet-Draft will expire on July 9, 2013.</p> 
     553      <p>This Internet-Draft will expire on July 12, 2013.</p> 
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 
    555555      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 
     
    20852085         although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request that contained the Upgrade header field. 
    20862086      </p> 
    2087       <p id="rfc.section.6.7.p.7">For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, then it <em class="bcp14">MUST</em> first respond with a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> message in HTTP/1.1 and then immediately follow that with the new protocol's equivalent of a response to a GET on the target 
     2087      <p id="rfc.section.6.7.p.7">For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, then it 
     2088         first responds with a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> message in HTTP/1.1 and then immediately follows that with the new protocol's equivalent of a response to a GET on the target 
    20882089         resource. This allows a connection to be upgraded to protocols with the same semantics as HTTP without the latency cost of 
    20892090         an additional round-trip. A server <em class="bcp14">MUST NOT</em> switch protocols unless the received message semantics can be honored by the new protocol; an OPTIONS request can be honored 
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2086 r2101  
    30593059<t> 
    30603060   For example, if the Upgrade header field is received in a GET request 
    3061    and the server decides to switch protocols, then it &MUST; first respond 
     3061   and the server decides to switch protocols, then it first responds 
    30623062   with a <x:ref>101 (Switching Protocols)</x:ref> message in HTTP/1.1 and 
    3063    then immediately follow that with the new protocol's equivalent of a 
     3063   then immediately follows that with the new protocol's equivalent of a 
    30643064   response to a GET on the target resource.  This allows a connection to be 
    30653065   upgraded to protocols with the same semantics as HTTP without the 
Note: See TracChangeset for help on using the changeset viewer.