Comments (15)
I'm sceptical about the "protect CGI servers" (and servers similar to those). We have 2020; shouldn't these all have their own protections by now?
Those CGI servers cannot protect themselves. The issue is that both hyphens and underscores are converted to underscores in CGI servers, so both Content-Length
and Content_Length
are converted to CONTENT_LENGTH
at the protocol level, and CGI servers cannot tell which HTTP header did it originate from, since that information is lost.
from http-core.
Hey Piotr,
We chatted about that here and tend to agree -- will remove underscore and see how that goes down.
from http-core.
My opinion is that Apache httpd team would prefer to reduce the syntax to reduce the security issues.
from http-core.
Discussed in Montreal; interest in doing something, take to list.
from http-core.
I'm not sure why this is being considered. All browsers support headers such as !#$%&'*+-.^_`|~0123456789abcdefghijklmnopqrstuvwxyz
. Changing that seems likely to break applications.
from http-core.
The restrictions exist to protect legacy server gateways (like CGI) that are far more restrictive than browsers need to be due to the terrible idea of passing names through env vars and command-lines.
from http-core.
in bkk: no real consensus, concern about compatibility. reconsider on impact of a case by cases
from http-core.
For the record, NGINX drops request header fields with names containing characters other than letters, digits, hyphens and optionally underscores (if configured using underscores_in_headers
directive). Unfortunately, virtually anything seems to be accepted and forwarded in the response headers.
from http-core.
Since I'm seeing the conversation moved from the WG to GH, I'm just pasting what I sent there for completeness. Right now haproxy only accepts :
"-" / "_" / "." / "+" / DIGIT / ALPHA / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "^" / "`" / "|" / "~"
i.e. everything matching a token. Quite honestly, seeing any character from this extra list in a field name would look extremely suspicious to me, and I'd rather get rid of them.
As Roy mentioned, the restriction is to avoid trouble with CGIs doing :
eval "hdr_name=$value"
Characters like backquote (`), dollar ($), or pipe(|) have long been abused to attack servers...
from http-core.
Also I proposed that we could do something less extreme than blocking messages containing such header field names, we could recommend to simply drop these fields by default. This will have no impact if they're here by accident. Then we can let the agents decide if they want to let them pass or not. Thus we could make the difference between "forbidden characters" (the historical ones) and "unusual characters" (those excluded by the new, more restrictive list).
from http-core.
Discussed in Bangkok, but no consensus on an approach.
from http-core.
ietf104: still seeking data for characters used in the wild. http archive mentioned as a possible source.
from http-core.
I'm sceptical about the "protect CGI servers" (and servers similar to those). We have 2020; shouldn't these all have their own protections by now?
from http-core.
Discussed in Basel; suggestion is to document "safe" characters in prose (for now), both below the ABNF and in the new header field recommendations.
from http-core.
Well, to be clear, it is the HTTP server that invokes CGI that is creating the environment variables from the received header fields. That server is responsible for avoiding bad transformations, such as the underscore problem above. However, since we are just talking about the characters that are good practice, we can exclude underscores since they are not commonly used in field names.
from http-core.
Related Issues (20)
- RFC 9110 does change requirements from RFC 2818 HOT 1
- Definition of status code 308 should mention that request method MUST NOT be changed
- multiple locations for 301/308 redirects? HOT 5
- how to handle C-L for unknown methods HOT 3
- incorrect media type weight in example
- A Single LF Line Terminator in RFC 9112 HOT 4
- OWS in ranges-specifier missing(?)
- charset names are used in Accept-Charset, not Accept-Encoding HOT 1
- http 1.1 message body (section 6) and get/head/delete semantics HOT 1
- If-Range distinguishing entity-tag from HTTP-date can be more refined HOT 1
- Missing changes - determining target URI authority
- absolute-form explanations are a bit confusing
- Media Type message/http requirements HOT 1
- Semantics of informational responses. HOT 2
- Caching: Vary, Conneg, and choosing the latest response HOT 1
- Caching: give caches more flexibility to calculate Age
- If-Match and caching intermediaries HOT 1
- rfc 9112: incorrect link in ABNF
- Clarification on messages with invalid Content-Length and valid Transfer-Encoding HOT 8
- RFC 9110, section 8.6: Incorrect use of the word "exception."
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from http-core.