- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 1 Apr 2015 21:12:17 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Julian, On Wed, Apr 01, 2015 at 10:09:16AM +0200, Julian Reschke wrote: > On 2015-03-31 22:56, Poul-Henning Kamp wrote: > >-------- > >In message <20150331182521.GF7183@1wt.eu>, Willy Tarreau writes: > > > >>>Third, are there *any* valid reasons to even allow other charsets > >>>than ISO-8859-1 or UTF-8 from 2015 forward ? > >> > >>Idem. And if we don't need to do more than that, then probably we > >>just need a boolean to say "this is not ISO-8859-1, hence this is > >>UTF-8" and make the encoding implicit by the sole presence of the > >>encoding tag (eg: the "*" or "=", I don't remember right now). > > > >In that case I could live with it being per field, because the > >signal could be a single character and we could probably > >dispense with the % encoding too. > > Friends, this is not a new format. It is implemented in all major user > agents, so it really doesn't make sense to invent a new shorter syntax > approximately 15 years after this has been defined first. Thanks for the info, I wasn't aware of it at all. So just for our understanding, could you explain in a few words what in your proposal differs from what already exists, or whether it standardizes something already used as a de-facto standard maybe ? I'm just trying to figure the level of flexibility that remains here. I must confess I don't feel very safe with having to parse any attribute this way if I need one. For instance, "q=0" for a compression token generally works fine, but its equivalent encoded form might probably not be handled by most servers. And for a gateway, having to do this n any header field might seem overkill at first glance. Best regards, Willy
Received on Wednesday, 1 April 2015 19:12:46 UTC