At 06:17 AM 2/14/2003, Graham Leggett wrote: >Maik Mueller wrote: > >>Putting arbitrary 8bit characters into headers makes me feel a bit uneasy >>but I couldn't find a quote that this is forbidden. > >Looking at this further, the header value is defined as TEXT. TEXT is defined as >OCTETs that are not control characters. An OCTET is an 8 bit character. As far as I >can see it should be up to the entity putting data into the header to make sure it >does not contain control characters. In your case, base64 would thus be safe.
I believe base64 (or a base95) encoding is vastly preferable to arbitrary octets. There are already modules that attempt to 'fix' the charset from the client, e.g. from an english client to a russian server, or dealing with the eastern character sets with utf-8. >>What do you think about my proposal to add the "E" option with the described >>behavior to the Header and RequestHeader directive? >>Keeping in mind that HTTP 1.0 still warns: >> >>>However, folding of header lines is not expected by some >>>applications, and should not be generated by HTTP/1.0 applications. > >HTTP 1.0 is obsolete - Apache follows HTTP/1.1, defined in RFC2616. Not only that, but these headers are sent *to* an Apache backend server that does expect those folded lines. I'm not reading that your encoded SSL datum would be passed back to any arbitrary client. Finally, I'm really concerned about the security aspect. Folks might not realize that by enabling this feature and neglecting to put the backend box behind the dmz (or even, passing this arbitrary new header through HTTP) - they would expose the backend server to fradulent credentials. Before we adopt this patch I'd the security aspect of the SSL-proxy -> credentials -> backend-server to see that resolved in the 80/20. We don't need a repeat of the HTTP port 25 proxy issue (a config issue - but that egg has landed in *our* face, not the admins of those open relays.) Bill
