Ignore:
Timestamp:
Aug 19, 2012, 6:10:39 PM (7 years ago)
Author:
fielding@…
Message:

move Via section up to routing (no changes)

File:
1 edited

Legend:

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

    r1834 r1835  
    24812481</section>
    24822482
     2483<section title="Via" anchor="header.via">
     2484  <iref primary="true" item="Via header field" x:for-anchor=""/>
     2485  <iref primary="true" item="Header Fields" subitem="Via" x:for-anchor=""/>
     2486  <x:anchor-alias value="pseudonym"/>
     2487  <x:anchor-alias value="received-by"/>
     2488  <x:anchor-alias value="received-protocol"/>
     2489  <x:anchor-alias value="Via"/>
     2490<t>
     2491   The "Via" header field &MUST; be sent by a proxy or gateway to
     2492   indicate the intermediate protocols and recipients between the user
     2493   agent and the server on requests, and between the origin server and
     2494   the client on responses. It is analogous to the "Received" field
     2495   used by email systems (<xref target="RFC5322" x:fmt="of" x:sec="3.6.7"/>)
     2496   and is intended to be used for tracking message forwards,
     2497   avoiding request loops, and identifying the protocol capabilities of
     2498   all senders along the request/response chain.
     2499</t>
     2500<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Via"/><iref primary="true" item="Grammar" subitem="received-protocol"/><iref primary="true" item="Grammar" subitem="protocol-name"/><iref primary="true" item="Grammar" subitem="protocol-version"/><iref primary="true" item="Grammar" subitem="received-by"/><iref primary="true" item="Grammar" subitem="pseudonym"/>
     2501  <x:ref>Via</x:ref>               = 1#( <x:ref>received-protocol</x:ref> <x:ref>RWS</x:ref> <x:ref>received-by</x:ref>
     2502                          [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] )
     2503  <x:ref>received-protocol</x:ref> = [ <x:ref>protocol-name</x:ref> "/" ] <x:ref>protocol-version</x:ref>
     2504  <x:ref>received-by</x:ref>       = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref>
     2505  <x:ref>pseudonym</x:ref>         = <x:ref>token</x:ref>
     2506</artwork></figure>
     2507<t>
     2508   The received-protocol indicates the protocol version of the message
     2509   received by the server or client along each segment of the
     2510   request/response chain. The received-protocol version is appended to
     2511   the Via field value when the message is forwarded so that information
     2512   about the protocol capabilities of upstream applications remains
     2513   visible to all recipients.
     2514</t>
     2515<t>
     2516   The protocol-name is excluded if and only if it would be "HTTP". The
     2517   received-by field is normally the host and optional port number of a
     2518   recipient server or client that subsequently forwarded the message.
     2519   However, if the real host is considered to be sensitive information,
     2520   it &MAY; be replaced by a pseudonym. If the port is not given, it &MAY;
     2521   be assumed to be the default port of the received-protocol.
     2522</t>
     2523<t>
     2524   Multiple Via field values represent each proxy or gateway that has
     2525   forwarded the message. Each recipient &MUST; append its information
     2526   such that the end result is ordered according to the sequence of
     2527   forwarding applications.
     2528</t>
     2529<t>
     2530   Comments &MAY; be used in the Via header field to identify the software
     2531   of each recipient, analogous to the <x:ref>User-Agent</x:ref> and
     2532   <x:ref>Server</x:ref> header fields. However, all comments in the Via field
     2533   are optional and &MAY; be removed by any recipient prior to forwarding the
     2534   message.
     2535</t>
     2536<t>
     2537   For example, a request message could be sent from an HTTP/1.0 user
     2538   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
     2539   forward the request to a public proxy at p.example.net, which completes
     2540   the request by forwarding it to the origin server at www.example.com.
     2541   The request received by www.example.com would then have the following
     2542   Via header field:
     2543</t>
     2544<figure><artwork type="example">
     2545  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
     2546</artwork></figure>
     2547<t>
     2548   A proxy or gateway used as a portal through a network firewall
     2549   &SHOULD-NOT; forward the names and ports of hosts within the firewall
     2550   region unless it is explicitly enabled to do so. If not enabled, the
     2551   received-by host of any host behind the firewall &SHOULD; be replaced
     2552   by an appropriate pseudonym for that host.
     2553</t>
     2554<t>
     2555   A proxy or gateway &MAY; combine an ordered subsequence of Via header
     2556   field entries into a single such entry if the entries have identical
     2557   received-protocol values. For example,
     2558</t>
     2559<figure><artwork type="example">
     2560  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     2561</artwork></figure>
     2562<t>
     2563  could be collapsed to
     2564</t>
     2565<figure><artwork type="example">
     2566  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
     2567</artwork></figure>
     2568<t>
     2569   Senders &SHOULD-NOT; combine multiple entries unless they are all
     2570   under the same organizational control and the hosts have already been
     2571   replaced by pseudonyms. Senders &MUST-NOT; combine entries which
     2572   have different received-protocol values.
     2573</t>
     2574</section>
     2575
    24832576<section title="Message Transforming" anchor="message.transforming">
    24842577<t>
     
    26562749   include the "close" connection option in every response message that
    26572750   does not have a <x:ref>1xx (Informational)</x:ref> status code.
    2658 </t>
    2659 </section>
    2660 
    2661 <section title="Via" anchor="header.via">
    2662   <iref primary="true" item="Via header field" x:for-anchor=""/>
    2663   <iref primary="true" item="Header Fields" subitem="Via" x:for-anchor=""/>
    2664   <x:anchor-alias value="pseudonym"/>
    2665   <x:anchor-alias value="received-by"/>
    2666   <x:anchor-alias value="received-protocol"/>
    2667   <x:anchor-alias value="Via"/>
    2668 <t>
    2669    The "Via" header field &MUST; be sent by a proxy or gateway to
    2670    indicate the intermediate protocols and recipients between the user
    2671    agent and the server on requests, and between the origin server and
    2672    the client on responses. It is analogous to the "Received" field
    2673    used by email systems (<xref target="RFC5322" x:fmt="of" x:sec="3.6.7"/>)
    2674    and is intended to be used for tracking message forwards,
    2675    avoiding request loops, and identifying the protocol capabilities of
    2676    all senders along the request/response chain.
    2677 </t>
    2678 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Via"/><iref primary="true" item="Grammar" subitem="received-protocol"/><iref primary="true" item="Grammar" subitem="protocol-name"/><iref primary="true" item="Grammar" subitem="protocol-version"/><iref primary="true" item="Grammar" subitem="received-by"/><iref primary="true" item="Grammar" subitem="pseudonym"/>
    2679   <x:ref>Via</x:ref>               = 1#( <x:ref>received-protocol</x:ref> <x:ref>RWS</x:ref> <x:ref>received-by</x:ref>
    2680                           [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] )
    2681   <x:ref>received-protocol</x:ref> = [ <x:ref>protocol-name</x:ref> "/" ] <x:ref>protocol-version</x:ref>
    2682   <x:ref>received-by</x:ref>       = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref>
    2683   <x:ref>pseudonym</x:ref>         = <x:ref>token</x:ref>
    2684 </artwork></figure>
    2685 <t>
    2686    The received-protocol indicates the protocol version of the message
    2687    received by the server or client along each segment of the
    2688    request/response chain. The received-protocol version is appended to
    2689    the Via field value when the message is forwarded so that information
    2690    about the protocol capabilities of upstream applications remains
    2691    visible to all recipients.
    2692 </t>
    2693 <t>
    2694    The protocol-name is excluded if and only if it would be "HTTP". The
    2695    received-by field is normally the host and optional port number of a
    2696    recipient server or client that subsequently forwarded the message.
    2697    However, if the real host is considered to be sensitive information,
    2698    it &MAY; be replaced by a pseudonym. If the port is not given, it &MAY;
    2699    be assumed to be the default port of the received-protocol.
    2700 </t>
    2701 <t>
    2702    Multiple Via field values represent each proxy or gateway that has
    2703    forwarded the message. Each recipient &MUST; append its information
    2704    such that the end result is ordered according to the sequence of
    2705    forwarding applications.
    2706 </t>
    2707 <t>
    2708    Comments &MAY; be used in the Via header field to identify the software
    2709    of each recipient, analogous to the <x:ref>User-Agent</x:ref> and
    2710    <x:ref>Server</x:ref> header fields. However, all comments in the Via field
    2711    are optional and &MAY; be removed by any recipient prior to forwarding the
    2712    message.
    2713 </t>
    2714 <t>
    2715    For example, a request message could be sent from an HTTP/1.0 user
    2716    agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
    2717    forward the request to a public proxy at p.example.net, which completes
    2718    the request by forwarding it to the origin server at www.example.com.
    2719    The request received by www.example.com would then have the following
    2720    Via header field:
    2721 </t>
    2722 <figure><artwork type="example">
    2723   Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    2724 </artwork></figure>
    2725 <t>
    2726    A proxy or gateway used as a portal through a network firewall
    2727    &SHOULD-NOT; forward the names and ports of hosts within the firewall
    2728    region unless it is explicitly enabled to do so. If not enabled, the
    2729    received-by host of any host behind the firewall &SHOULD; be replaced
    2730    by an appropriate pseudonym for that host.
    2731 </t>
    2732 <t>
    2733    A proxy or gateway &MAY; combine an ordered subsequence of Via header
    2734    field entries into a single such entry if the entries have identical
    2735    received-protocol values. For example,
    2736 </t>
    2737 <figure><artwork type="example">
    2738   Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    2739 </artwork></figure>
    2740 <t>
    2741   could be collapsed to
    2742 </t>
    2743 <figure><artwork type="example">
    2744   Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    2745 </artwork></figure>
    2746 <t>
    2747    Senders &SHOULD-NOT; combine multiple entries unless they are all
    2748    under the same organizational control and the hosts have already been
    2749    replaced by pseudonyms. Senders &MUST-NOT; combine entries which
    2750    have different received-protocol values.
    27512751</t>
    27522752</section>
Note: See TracChangeset for help on using the changeset viewer.