Application handling of field names

Fixes #843

draft-ietf-httpbis-semantics-latest.xml

@@ -10016,7 +10016,9 @@ Content-Type: text/plain
    practice some implementations place limits on the characters they accept
    in field-names. To be interoperable, new field names &SHOULD; constrain
    themselves to alphanumeric characters, "-", and ".", and &SHOULD;
-   begin with an alphanumeric character.
+   begin with an alphanumeric character. In particular, the "_" character
+   can be problematic because of how some implementations treat it;
+   see <xref target="underscore.in.fields"/>.
 </t>
 <t>
    Field names ought not be prefixed with "X-"; see
@@ -10599,6 +10601,35 @@ Content-Type: text/plain
 </t>
 </section>
 
+<section title="Application Handling of Field Names" anchor="underscore.in.fields">
+<t>
+   When an implementation makes HTTP fields available to an application, it
+   is often necessary to map field names into an application-specific name
+   space. Most commonly, this is done by changing all instances of "-" to
+   "_", and prepending "HTTP_". For example, "Content-Length" might become
+   "HTTP_CONTENT_LENGTH".
+</t>
+<t>
+   This practice can lead to security vulnerabilities. For example, if an
+   attacker were to send a header named "Http_Content_Length", a naive
+   application might use that value instead of the intended one. Most often,
+   the resulting vulnerability takes the form of request smuggling (<xref
+   target="request.smuggling"/>).
+</t>
+<t>
+   For this reason, <xref target="considerations.for.new.field.names"/>
+   discourages new fields from using names containing the "_" character.
+</t>
+<t>
+   To mitigate the associated risks, implementations that perform such
+   mapping are advised to handle an incoming field whose name contains "_"
+   carefully. For example, the field might be completely removed, or it might
+   be made available with a different prefix, to distinguish it from fields
+   containing "-".
+</t>
+
+</section>
+
 <section title="Disclosure of Fragment after Redirects" anchor="fragment.disclosure">
 <t>
    Although fragment identifiers used within URI references are not sent
@@ -13543,6 +13574,7 @@ Content-Type: text/plain
   <li>In <xref target="HEAD"/>, align prose about content in HEAD requests with description of GET (<eref target="https://github.com/httpwg/http-core/issues/826"/>)</li>
   <li>In <xref target="fields.order"/>, remove the restriction to non-empty field line values (<eref target="https://github.com/httpwg/http-core/issues/836"/>)</li>
   <li>Add forward references to definition of OWS (<eref target="https://github.com/httpwg/http-core/issues/841"/>)</li>
+  <li>In <xref target="underscore.in.fields"/>, add a security consideration regarding application handling of field names (<eref target="https://github.com/httpwg/http-core/issues/843"/>)</li>
 </ul>
 </section>
 </section>