Ignore:
Timestamp:
Mar 30, 2012, 8:52:18 AM (7 years ago)
Author:
julian.reschke@…
Message:

Step 8 of p2/p3-merge (see #351)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1645 r1646  
    39963996</t>
    39973997</section>
     3998
     3999<section title="Content Coding Registry" anchor="content.coding.registration">
     4000<t>
     4001   The registration procedure for HTTP Content Codings is now defined
     4002   by <xref target="content.coding.registry"/> of this document.
     4003</t>
     4004<t>
     4005   The HTTP Content Codings Registry located at <eref target="http://www.iana.org/assignments/http-parameters"/>
     4006   shall be updated with the registration below:
     4007</t>
     4008<texttable align="left" suppress-title="true" anchor="iana.content.coding.registration.table">
     4009   <ttcol>Name</ttcol>
     4010   <ttcol>Description</ttcol>
     4011   <ttcol>Reference</ttcol>
     4012   <c>compress</c>
     4013   <c>UNIX "compress" program method</c>
     4014   <c>
     4015      &compress-coding;
     4016   </c>
     4017   <c>deflate</c>
     4018   <c>"deflate" compression mechanism (<xref target="RFC1951"/>) used inside
     4019   the "zlib" data format (<xref target="RFC1950"/>)
     4020   </c>
     4021   <c>
     4022      &deflate-coding;
     4023   </c>
     4024   <c>gzip</c>
     4025   <c>Same as GNU zip <xref target="RFC1952"/></c>
     4026   <c>
     4027      &gzip-coding;
     4028   </c>
     4029   <c>identity</c>
     4030   <c>reserved (synonym for "no encoding" in Accept-Encoding header field)</c>
     4031   <c>
     4032      <xref target="header.accept-encoding"/>
     4033   </c>
     4034</texttable>
     4035</section>
     4036
    39984037</section>
    39994038
     
    41204159   via SMTP, for example. As such, proxies &SHOULD; restrict CONNECT
    41214160   access to a small number of known ports.
     4161</t>
     4162</section>
     4163
     4164<section title="Privacy Issues Connected to Accept Header Fields" anchor="privacy.issues.connected.to.accept.header.fields">
     4165<t>
     4166   Accept header fields can reveal information about the user to all
     4167   servers which are accessed. The Accept-Language header field in particular
     4168   can reveal information the user would consider to be of a private
     4169   nature, because the understanding of particular languages is often
     4170   strongly correlated to the membership of a particular ethnic group.
     4171   User agents which offer the option to configure the contents of an
     4172   Accept-Language header field to be sent in every request are strongly
     4173   encouraged to let the configuration process include a message which
     4174   makes the user aware of the loss of privacy involved.
     4175</t>
     4176<t>
     4177   An approach that limits the loss of privacy would be for a user agent
     4178   to omit the sending of Accept-Language header fields by default, and to ask
     4179   the user whether or not to start sending Accept-Language header fields to a
     4180   server if it detects, by looking for any Vary header fields
     4181   generated by the server, that such sending could improve the quality
     4182   of service.
     4183</t>
     4184<t>
     4185   Elaborate user-customized accept header fields sent in every request,
     4186   in particular if these include quality values, can be used by servers
     4187   as relatively reliable and long-lived user identifiers. Such user
     4188   identifiers would allow content providers to do click-trail tracking,
     4189   and would allow collaborating content providers to match cross-server
     4190   click-trails or form submissions of individual users. Note that for
     4191   many users not behind a proxy, the network address of the host
     4192   running the user agent will also serve as a long-lived user
     4193   identifier. In environments where proxies are used to enhance
     4194   privacy, user agents ought to be conservative in offering accept
     4195   header configuration options to end users. As an extreme privacy
     4196   measure, proxies could filter the accept header fields in relayed requests.
     4197   General purpose user agents which provide a high degree of header
     4198   configurability &SHOULD; warn users about the loss of privacy which can
     4199   be involved.
    41224200</t>
    41234201</section>
     
    60466124</section>
    60476125
    6048 
    6049 <section title="IANA Considerations" anchor="IANA.considerations3">
    6050 
    6051 <section title="Content Coding Registry" anchor="content.coding.registration">
    6052 <t>
    6053    The registration procedure for HTTP Content Codings is now defined
    6054    by <xref target="content.coding.registry"/> of this document.
    6055 </t>
    6056 <t>
    6057    The HTTP Content Codings Registry located at <eref target="http://www.iana.org/assignments/http-parameters"/>
    6058    shall be updated with the registration below:
    6059 </t>
    6060 <texttable align="left" suppress-title="true" anchor="iana.content.coding.registration.table">
    6061    <ttcol>Name</ttcol>
    6062    <ttcol>Description</ttcol>
    6063    <ttcol>Reference</ttcol>
    6064    <c>compress</c>
    6065    <c>UNIX "compress" program method</c>
    6066    <c>
    6067       &compress-coding;
    6068    </c>
    6069    <c>deflate</c>
    6070    <c>"deflate" compression mechanism (<xref target="RFC1951"/>) used inside
    6071    the "zlib" data format (<xref target="RFC1950"/>)
    6072    </c>
    6073    <c>
    6074       &deflate-coding;
    6075    </c>
    6076    <c>gzip</c>
    6077    <c>Same as GNU zip <xref target="RFC1952"/></c>
    6078    <c>
    6079       &gzip-coding;
    6080    </c>
    6081    <c>identity</c>
    6082    <c>reserved (synonym for "no encoding" in Accept-Encoding header field)</c>
    6083    <c>
    6084       <xref target="header.accept-encoding"/>
    6085    </c>
    6086 </texttable>
    6087 </section>
    6088 
    6089 </section>
    6090 
    6091 <section title="Security Considerations" anchor="security.considerations3">
    6092 <t>
    6093    This section is meant to inform application developers, information
    6094    providers, and users of the security limitations in HTTP/1.1 as
    6095    described by this document. The discussion does not include
    6096    definitive solutions to the problems revealed, though it does make
    6097    some suggestions for reducing security risks.
    6098 </t>
    6099 
    6100 <section title="Privacy Issues Connected to Accept Header Fields" anchor="privacy.issues.connected.to.accept.header.fields">
    6101 <t>
    6102    Accept header fields can reveal information about the user to all
    6103    servers which are accessed. The Accept-Language header field in particular
    6104    can reveal information the user would consider to be of a private
    6105    nature, because the understanding of particular languages is often
    6106    strongly correlated to the membership of a particular ethnic group.
    6107    User agents which offer the option to configure the contents of an
    6108    Accept-Language header field to be sent in every request are strongly
    6109    encouraged to let the configuration process include a message which
    6110    makes the user aware of the loss of privacy involved.
    6111 </t>
    6112 <t>
    6113    An approach that limits the loss of privacy would be for a user agent
    6114    to omit the sending of Accept-Language header fields by default, and to ask
    6115    the user whether or not to start sending Accept-Language header fields to a
    6116    server if it detects, by looking for any Vary header fields
    6117    generated by the server, that such sending could improve the quality
    6118    of service.
    6119 </t>
    6120 <t>
    6121    Elaborate user-customized accept header fields sent in every request,
    6122    in particular if these include quality values, can be used by servers
    6123    as relatively reliable and long-lived user identifiers. Such user
    6124    identifiers would allow content providers to do click-trail tracking,
    6125    and would allow collaborating content providers to match cross-server
    6126    click-trails or form submissions of individual users. Note that for
    6127    many users not behind a proxy, the network address of the host
    6128    running the user agent will also serve as a long-lived user
    6129    identifier. In environments where proxies are used to enhance
    6130    privacy, user agents ought to be conservative in offering accept
    6131    header configuration options to end users. As an extreme privacy
    6132    measure, proxies could filter the accept header fields in relayed requests.
    6133    General purpose user agents which provide a high degree of header
    6134    configurability &SHOULD; warn users about the loss of privacy which can
    6135    be involved.
    6136 </t>
    6137 </section>
    6138 
    6139 </section>
    6140 
    6141 
    61426126<section title="Differences between HTTP and MIME" anchor="differences.between.http.and.mime">
    61436127<t>
Note: See TracChangeset for help on using the changeset viewer.