general/6315: apache_1.3.12 and getline() interprets a single "\n" as element separator

[Doug Hood <ho...@issl.atl.hp.com>]

>Number:         6315
>Category:       general
>Synopsis:       apache_1.3.12 and getline() interprets a single "\n" as element separator
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Fri Jul 14 09:30:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     hood@issl.atl.hp.com
>Release:        1.3.12
>Organization:
apache
>Environment:
HPUX  B.11.04 9000/803
HP cc compiler
>Description:
When proxying a client certificate (in the request header) from an NES 4.x 
server to Apache 1.3.12,  the Apache server puts out the error message: 
<start of error>
Bad Request

Your browser sent a request that this server could not understand.

Request header field is missing colon separator.

A1UECBMHR2VvcmdpYTEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkx

<end of error> 

In examining the header using tusc on HPUX, I noted that the header comes 
through in the form:

proxy-client-cert: MIICqzCCAhQCAgJkMA0GCSqGSIb3DQEBBAUAMIGUMQswCQYDVQQGEwJVU
zEQMA4G\nA1UECBMHR2VvcmdpYTEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkx\nKTAnB
gNVBAsTIEludGVBAsT\nIEludGVybmV0IGFuZCBTeXN0ZW0gU2VjdXJpdHkgTGFiMRIwEAYDVQQDEwlE
b3Vn\nIEhvb2QxIzAhBgkqhkiG9w0BCQEWFGhvb2RAABMA0GCSqGSIb3DQEBBAUAA4GBAG/eJOyFDPwb
clrK2x5EWYPB\nzAlILl5UHENGiRoaAwlhlAfsZiXQ6BhSYr6qwvni6i+ULbwu0UVeT2GWCVNEfOxH\n
+/xdj9WE1SpQ/lJe28magVuFMUIvc0o4Ra0lU5MHKLkACpGczFyI+uVHsofRUYcy\nvNoNyb6kO2c
FmV9bj/BR


You'll note the embedded "\n" characters in the certificate. It appears that getline() 
in http_protocol.c looks only for "\n" in determining separation of header fields. 
The embedded "\n" characters cause getline() to interpret each portion of the cert as 
a different request header field.

RFC 2068 (HTTP/1.1 spec) section 4.2 gives the common form of a message header to be:

message-header = field-name ":" [field-value] CRLF 
>How-To-Repeat:
Thats a tough one.  I saw this problem by forwarding a certificate in an NES NSAPI 
that proxies requests... and the resulting request was refused by Apache. 
>Fix:
Rewrite getline() to use the CRLF pair to determine how to parse the line into 
messages headers rather than the single LF character
>Release-Note:
>Audit-Trail:
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <ap...@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]