PROXY  WHOIS  RQUOTE  TEXTS  SOFT  FOREX  BBOARD
 Music  Philosophy  Code  Literature  Russian

= ROOT|Technical|Proxy_Docs|rfc2295.txt =

page 2 of 33



    10.3 Adhoc response..........................................37
    10.4 Reusing the Alternates header...........................38
    10.5 Extracting a normal response from a choice response.....39
    10.6 Elaborate Vary headers..................................39
    10.6.1 Construction of an elaborate Vary header..............40
    10.6.2 Caching of an elaborate Vary header...................41
    10.7 Adding an Expires header for HTTP/1.0 compatibility.....41
    10.8 Negotiation on content encoding.........................41





 
RFC 2295            Transparent Content Negotiation           March 1998


   11 User agent support for transparent negotiation.............42
    11.1 Handling of responses...................................42
    11.2 Presentation of a transparently negotiated resource.....42

   12 Origin server support for transparent negotiation..........43
    12.1 Requirements............................................43
    12.2 Negotiation on transactions other than GET and HEAD.....45

   13 Proxy support for transparent negotiation..................45

   14 Security and privacy considerations........................46
    14.1 Accept- headers revealing personal information..........46
    14.2 Spoofing of responses from variant resources............47
    14.3 Security holes revealed by negotiation..................47

   15 Internationalization considerations........................47

   16 Acknowledgments............................................47

   17 References.................................................48

   18 Authors' Addresses.........................................48

   19 Appendix: Example of a local variant selection algorithm...49
    19.1 Computing overall quality values........................49
    19.2 Determining the result..................................51
    19.3 Ranking dimensions......................................51

   20 Appendix: feature negotiation examples.....................52
    20.1 Use of feature tags.....................................52
    20.2 Use of numeric feature tags.............................53
    20.3 Feature tag design......................................53

   21 Appendix: origin server implementation considerations......54
    21.1 Implementation with a CGI script........................54
    21.2 Direct support by HTTP servers..........................55
    21.3 Web publishing tools....................................55

   22 Appendix: Example of choice response construction..........55

   23 Full Copyright Statement...................................58











 
RFC 2295            Transparent Content Negotiation           March 1998


1  Introduction

   HTTP allows web site authors to put multiple versions of the same
   information under a single URI.  Each of these versions is called a
   `variant'.  Transparent content negotiation is an extensible
   negotiation mechanism for automatically and efficiently retrieving
   the best variant when a GET or HEAD request is made.  This enables
   the smooth deployment of new web data formats and markup tags.

   This specification defines transparent content negotiation as an
   extension on top of the HTTP/1.1 protocol [1].  However, use of this
   extension does not require use of HTTP/1.1: transparent content
   negotiation can also be done if some or all of the parties are
   HTTP/1.0 [2] systems.

   Transparent content negotiation is called `transparent' because it
   makes all variants which exist inside the origin server visible to
   outside parties.

     Note: Some members of the IETF are currently undertaking a number
     of activities which are loosely related to this experimental
     protocol.  First, there is an effort to define a protocol-
     independent registry for feature tags.  The intention is that this
     experimental protocol will be one of the clients of the registry.
     Second, some research is being done on content negotiation systems
     for other transport protocols (like internet mail and internet fax)
     and on generalized negotiation systems for multiple transport
=2=

1| < PREV = PAGE 2 = NEXT > |3|4|5|6|7|8|9|10|11.33

UP TO ROOT | UP TO DIR | TO FIRST PAGE

Google
 


E-mail Facebook Google Digg del.icio.us BlinkList Fark Furl Ma.gnolia Netscape NewsVine Reddit Slashdot Spurl StumbleUpon Technorati YahooMyWeb LiveJournal Blogmarks TwitThis Live News2.ru BobrDobr.ru Memori.ru MoeMesto.ru

0.0260801 wallclock secs ( 0.01 usr + 0.00 sys = 0.01 CPU)