https://issues.apache.org/bugzilla/show_bug.cgi?id=54703
--- Comment #5 from Mark Thomas <ma...@apache.org> --- Short version: The arguments present here aren't valid but they did cause me to look at this again and there is a case for changing the current behaviour. Long version: 1. A regression is when valid behaviour is broken. Using CR or LF in setHeader() is not valid behaviour (see point 2) so this is not a regression. The question here is how tolerant should Tomcat be when an application presents invalid input. Those goalposts may be moved and any changes in behaviour will not get treated as regressions (I usually withdraw an in progress release if we find a regression). 2. If a HTTP header is folded, getHeader() returns the unfolded value. If it did anything else, lots of applications would break. Logically, setHeader() and getHeader() should be symmetric. Therefore, they work with the header value not the "on the wire" representation. If this was different, I'd expect to see it called out in the specification. It isn't. As an aside, cookies values are handled the same way to avoid a bunch of security issues. See CVE-2007-3385, CVE-2007-3382 & CVE-2007-5333. 3. The format used on the wire is irrelevant. See point 2. Note that proxies are free to unfold headers if they wish. There is no point an application trying to specify that a header should be folded because a proxy can unfold it. 4. The idea here is along the right lines but there is a better way to implement it. The skipping of LWS can be pulled out into a separate function and CR and LF added to the characters that are skipped. Currently they are not handled as for input Tomcat has already unfolded all headers and for output the application shouldn't use using them. I took a careful look at the Tomcat code while I was researching this response and I believe there is an argument for taking a different approach. Generally, Tomcat doesn't validate what gets passed to setHeader() but it does in a few cases where the header value has an impact on Tomcat's processing (Content-Type, Content-Length). Tomcat refers to these as special headers. If the value passed to setHeader() for a special header is invalid (e.g. non-numeric content length) then Tomcat simply ignores it and passes it to the client as is on the basis the application really does know what it is doing. It is arguable that Tomcat should not do this (servers should be strict in what they send and tolerant in what they accept) but it does mean that applications are given some leeway to bend the HTTP spec if they need to on the understanding that if they shoot themselves in the foot then any resulting mess is an application responsibility (and with headers there are likely to be security implications). How far application servers should go to stop developers shooting themselves in the foot - particularly from a security perspective - is a matter of debate. Certainly validating all header values and dropping invalid ones should be more secure but it would come at a price both in code complexity (writing parsing code for all the headers in RFC2616 would not be fun) and performance. Getting back to the original point, it is clear from the current code that the intention is to parse headers where they can be parsed and ignore them otherwise - not to validate them and reject invalid headers. Therefore a CR or LF in a header value should not cause the response to fail. The question is whether to just ignore the invalid header (and pass it through to the client as-is) or to do as suggested in point 4 and treat all LWS as a single space. I can't see any down side to the latter approach and it has the upside if that there is data there Tomcat needs it can extract it. Therefore I will look at implementing this for the next 7.0.x release. Note that this means that any folded content-type header values passed to setHeader() and friends will be unfolded by Tomcat before it is written to the wire. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
