- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Fri, 14 Mar 2008 11:55:33 +0100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Martin Duerst <duerst@it.aoyama.ac.jp>, Brian Smith <brian@briansmith.org>, ietf-http-wg@w3.org
Am 14.03.2008 um 11:46 schrieb Mark Nottingham: > > I think Larry was making much the same point at the app area arch > ws, IIRC. > > My gut feeling on issue 74 is that if any encoding (e.g., IRI->URI, > RFC2047) is usable in a header, it should be specified on a header- > by-header basis explicitly, not inherited as a general rule like > this. That allows the flexibility to use the right mechanism for > the job, and keeps the overhead low. > > Are there any other headers (besides URI-based headers) that we > need to consider, beyond these? > * WWW-Authenticate, Proxy-Authenticate, Authorization, Proxy- > Authorization > * Content-Disposition > * From > * Warning > * PICS-Label The whole "Auth" header series does not have the problem, I think. All header values are ASCII. Correct me if I'm wrong: the open issue is how to send user names/ passwords with non-ascii characters. But that is a matter of the auth mechanism to specify, not an issue with HTTP headers. Example: Basic puts Base64 values in the header. Those are always ASCII. But Base64 operates on octets and Basic just fails to specify how a username is converted to octets, right? //Stefan -- <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782
Received on Friday, 14 March 2008 10:56:11 UTC