Ignore:
Timestamp:
06/05/14 16:20:31 (6 years ago)
Author:
julian.reschke@…
Message:

mainly grammatical fixes (#553)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/auth48/p1-messaging.unpg.txt

    r2646 r2647  
    633633   [RFC7234].
    634634
    635    There are a wide variety of architectures and configurations of
    636    caches deployed across the World Wide Web and inside large
    637    organizations.  These include national hierarchies of proxy caches to
    638    save transoceanic bandwidth, collaborative systems that broadcast or
     635   There is a wide variety of architectures and configurations of caches
     636   deployed across the World Wide Web and inside large organizations.
     637   These include national hierarchies of proxy caches to save
     638   transoceanic bandwidth, collaborative systems that broadcast or
    639639   multicast cache entries, archives of pre-fetched cache entries for
    640640   use in off-line or high-latency environments, and so on.
     
    669669   When a received protocol element is parsed, the recipient MUST be
    670670   able to parse any value of reasonable length that is applicable to
    671    the recipient's role and matches the grammar defined by the
     671   the recipient's role and that matches the grammar defined by the
    672672   corresponding ABNF rules.  Note, however, that some received protocol
    673673   elements might not be parsed.  For example, an intermediary
     
    111811183.1.  Start Line
    11191119
    1120    An HTTP message can either be a request from client to server or a
     1120   An HTTP message can be either a request from client to server or a
    11211121   response from server to client.  Syntactically, the two types of
    11221122   message differ only in the start-line, which is either a request-line
     
    13781378   processed).  Consequently, this specification does not use ABNF rules
    13791379   to define each "Field-Name: Field Value" pair, as was done in
    1380    previous editions.  Instead, this specification uses ABNF rules which
     1380   previous editions.  Instead, this specification uses ABNF rules that
    13811381   are named according to each registered field name, wherein the rule
    13821382   defines the valid grammar for that field's corresponding field values
     
    29522952   implemented by many HTTP/1.0 clients).
    29532953
    2954    See Appendix A.1.2 for more information on backward compatibility
     2954   See Appendix A.1.2 for more information on backwards compatibility
    29552955   with HTTP/1.0 clients.
    29562956
     
    29992999   response).  A server MAY process a sequence of pipelined requests in
    30003000   parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
    3001    but MUST send the corresponding responses in the same order that the
    3002    requests were received.
     3001   but it MUST send the corresponding responses in the same order that
     3002   the requests were received.
    30033003
    30043004   A client that pipelines requests SHOULD retry unanswered requests if
     
    32713271   until it has completely sent the request message (i.e., the client
    32723272   can't change the protocol it is sending in the middle of a message).
    3273    If a server receives both Upgrade and an Expect header field with the
    3274    "100-continue" expectation (Section 5.1.1 of [RFC7231]), the server
    3275    MUST send a 100 (Continue) response before sending a 101 (Switching
    3276    Protocols) response.
     3273   If a server receives both an Upgrade and an Expect header field with
     3274   the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the
     3275   server MUST send a 100 (Continue) response before sending a 101
     3276   (Switching Protocols) response.
    32773277
    32783278   The Upgrade header field only applies to switching protocols on top
     
    39703970   securely stored and appropriate guidelines followed for its analysis.
    39713971   Anonymization of personal information within individual entries
    3972    helps, but is generally not sufficient to prevent real log traces
     3972   helps, but it is generally not sufficient to prevent real log traces
    39733973   from being re-identified based on correlation with other access
    39743974   characteristics.  As such, access traces that are keyed to a specific
     
    43054305   requirements that enable reliable implementations, adding only those
    43064306   features that can either be safely ignored by an HTTP/1.0 recipient
    4307    or only sent when communicating with a party advertising conformance
    4308    with HTTP/1.1.
     4307   or only be sent when communicating with a party advertising
     4308   conformance with HTTP/1.1.
    43094309
    43104310   HTTP/1.1 has been designed to make supporting previous versions easy.
     
    44094409
    44104410   The HTTP-version ABNF production has been clarified to be case-
    4411    sensitive.  Additionally, version numbers has been restricted to
     4411   sensitive.  Additionally, version numbers have been restricted to
    44124412   single digits, due to the fact that implementations are known to
    44134413   handle multi-digit version numbers incorrectly.  (Section 2.6)
Note: See TracChangeset for help on using the changeset viewer.