Changeset 1835 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 20/08/12 01:10:39 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1834 r1835 2481 2481 </section> 2482 2482 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 2483 2576 <section title="Message Transforming" anchor="message.transforming"> 2484 2577 <t> … … 2656 2749 include the "close" connection option in every response message that 2657 2750 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 to2670 indicate the intermediate protocols and recipients between the user2671 agent and the server on requests, and between the origin server and2672 the client on responses. It is analogous to the "Received" field2673 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 of2676 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 message2687 received by the server or client along each segment of the2688 request/response chain. The received-protocol version is appended to2689 the Via field value when the message is forwarded so that information2690 about the protocol capabilities of upstream applications remains2691 visible to all recipients.2692 </t>2693 <t>2694 The protocol-name is excluded if and only if it would be "HTTP". The2695 received-by field is normally the host and optional port number of a2696 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 has2703 forwarded the message. Each recipient &MUST; append its information2704 such that the end result is ordered according to the sequence of2705 forwarding applications.2706 </t>2707 <t>2708 Comments &MAY; be used in the Via header field to identify the software2709 of each recipient, analogous to the <x:ref>User-Agent</x:ref> and2710 <x:ref>Server</x:ref> header fields. However, all comments in the Via field2711 are optional and &MAY; be removed by any recipient prior to forwarding the2712 message.2713 </t>2714 <t>2715 For example, a request message could be sent from an HTTP/1.0 user2716 agent to an internal proxy code-named "fred", which uses HTTP/1.1 to2717 forward the request to a public proxy at p.example.net, which completes2718 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 following2720 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 firewall2727 &SHOULD-NOT; forward the names and ports of hosts within the firewall2728 region unless it is explicitly enabled to do so. If not enabled, the2729 received-by host of any host behind the firewall &SHOULD; be replaced2730 by an appropriate pseudonym for that host.2731 </t>2732 <t>2733 A proxy or gateway &MAY; combine an ordered subsequence of Via header2734 field entries into a single such entry if the entries have identical2735 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 lucy2739 </artwork></figure>2740 <t>2741 could be collapsed to2742 </t>2743 <figure><artwork type="example">2744 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy2745 </artwork></figure>2746 <t>2747 Senders &SHOULD-NOT; combine multiple entries unless they are all2748 under the same organizational control and the hosts have already been2749 replaced by pseudonyms. Senders &MUST-NOT; combine entries which2750 have different received-protocol values.2751 2751 </t> 2752 2752 </section>
Note: See TracChangeset
for help on using the changeset viewer.