[PATCH] PR 16520 -- cache MUST NOT cache responses to Authorizationrequests

2003-06-09 Thread Kris Verbeeck
Actually this PR is not a mod_cache bug.  According to RFC 2616,
LWS might be present at the end of an HTTP header.
Quote from RFC 2616:
   implied *LWS
  The grammar described by this specification is word-based. Except
  where noted otherwise, linear white space (LWS) can be included
  between any two adjacent words (token or quoted-string), and
  between adjacent words and separators, without changing the
  interpretation of a field. At least one delimiter (LWS and/or
  separators) MUST exist between any two tokens (for the definition
  of token below), since they would otherwise be interpreted as a
  single token.
So, as PR 16520 states:

   Authorization  : scheme scheme param=value

is a valid header and should be treated as

   Authorization: scheme scheme param=value

Currently Apache does not strip any trailing LWS from the header name. 
The attached patch resolves this problem.

--
Index: server/protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/server/protocol.c,v
retrieving revision 1.131
diff -u -r1.131 protocol.c
--- server/protocol.c   15 Apr 2003 22:47:57 -  1.131
+++ server/protocol.c   9 Jun 2003 14:33:42 -
@@ -702,7 +702,7 @@
 apr_size_t last_len = 0;
 apr_size_t alloc_len = 0;
 char *field;
-char *value;
+char *value, *p;
 apr_size_t len;
 int fields_read = 0;
 apr_table_t *tmp_headers;
@@ -790,7 +790,12 @@
 return;
 }
 
-*value = '\0';
+p = value - 1;
+while ((last_field  p)  (*p == ' ' || *p == '\t')) {
+--p;/* Skip to end of name */
+}
+*(p+1) = '\0';
+
 ++value;
 while (*value == ' ' || *value == '\t') {
 ++value;/* Skip to start of value   */


Re: [PATCH] PR 16520 -- cache MUST NOT cache responses to Authorizationrequests

2003-06-09 Thread Kris Verbeeck
André Malo wrote:
So, there's just one token and no place for an implied LWS. [ situation
differs from between any two adjacent words (token or quoted-string) ]
So, as PR 16520 states:

   Authorization  : scheme scheme param=value

is a valid header and should be treated as

   Authorization: scheme scheme param=value


So these are not the same headers, by my reading of the RFC. In fact the
former is a Bad Request, since a token cannot contain WS.
nd
I wasn't 100% sure myself whether the LWS was allowed after the header 
name...  But is reporting a bad request not a bit drastic if removing 
the LWS can make it compliant?  This will make the server more lenient 
towards malformed header names.

But one of the two (stripping LWS or blocking request) should be done 
because, IMHO, this is a serious security issue.  There are back-end 
servers (in case Apache is used as a proxy) that strip white space from 
front and end of header names.  In that case Apache and the back-end 
will see different requests (e.g. the Authorization header).

--