Subject: Re: Call for Adoption: draft-reschke-rfc54987bis

From: Cory Benfield <[email-masked]>
Date: Wed, 1 Apr 2015 09:03:18 +0100

On 1 April 2015 at 02:18, Amos Jeffries <[email-masked]> wrote:
> That sound better to me.
> Amos

Me too.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Apr 2015 10:09:16 +0200

On 2015-03-31 22:56, Poul-Henning Kamp wrote:
> --------
> In message <[email-masked]>, 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.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Apr 2015 10:13:23 +0200

On 2015-03-31 07:42, Willy Tarreau wrote:
> On Tue, Mar 31, 2015 at 03:08:06PM +1100, Mark Nottingham wrote:
>> We discussed this document in Dallas:
>>    <http://tools.ietf.org/html/draft-reschke-rfc5987bis>
>>
>> Based on the feedback received, I believe that we should adopt this document
>> as a WG product, with a target of Proposed Standard.
>>
>> I've discussed it with our Area Director, who agrees that it's a reasonable
>> thing for us to do.
>>
>> Since this is a bis effort with a primary aim of aligning with RFC723x, I
>> think we can do this relatively quickly, with a target of going to IETF LC by
>> Prague.
>>
>> Please comment on-list; we???ll make a decision about adoption at the end of
>> the week.
>
> After a quick review, I think we should make it stricter. Currently,
> it suggests that recipients should be prepared to receive invalid code
> sequences but that can be dangerous when passing through multiple
> intermediaries because all of them could have different fallback
> methods. I'd rather make it clear that any recipient in the chain
> which finds an encoding issue must return a 400 bad req.

a) It's not the case right now. How do you want to get this change 
deployed in practice?

b) How do you want to signal an error on a *response*?

> Also, I'd prefer to make it explicitly forbidden to %-encode US-ASCII
> characters because this could be used to bypass some WAFs for example :
> if it is detected that a server implements this standard and is able
> to %-decode some attributes in header fields, and a WAF in the middle
> does not, the client can abuse the %-encoding to try to hide some
> activities.

Yes, that's the case right now. I'd argue that the spec has been out for 
ages, so the intermediary ought to be fixed.

> In addition to this, probably that we should make it clear that some
> characters must not be emitted nor encoded (NUL, CR, LF). The risk is
> that some intermediaries decode them and replace them before passing
> the request to the next hop and change the message header structure,
> resulting in issues similar to HTTP request smugling attacks.

I think that depends on the header field it is used in. For instance, 
RFC 6266 discusses these constraints for the filename parameter.

> Otherwise I think it could be useful indeed.

It already is, and has been for a long time.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Apr 2015 10:15:27 +0200

On 2015-03-31 16:40, Poul-Henning Kamp wrote:
> --------
> In message <[email-masked]>, Mark Nottingham wri
> tes:
>
>> Based on the feedback received, I believe that we should adopt this
>> document as a WG product, with a target of Proposed Standard.
>
> Solving the problem:  Yes, good idea.
>
> "Solving" it this way:  Bad idea.

It *has* been solved this way. This is not new.

> First, we're worried about transmission times for HTTP so making
> the charset selection per header-subfield is a horribly inefficient
> way to solve the problem.

Yes.

> Second, do we really want to make it possible to have one subfield
> of a header be KOIR8 and the next subfield be codepage 1251 ?

The spec clearly says that anything but UTF-8 might not be interoperable.

> than ISO-8859-1 or UTF-8 from 2015 forward ?

This is a legacy encoding; it goes back to RFC 2231 (and even more).

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Apr 2015 21:12:17 +0200

Hi Julian,

> 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

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Apr 2015 21:19:30 +0200

> a) It's not the case right now. How do you want to get this change 

Just like we said that multiple content-length values are not acceptable
if different despite most implementations not doing the check yet. I mean,
by not specifying the control, we can leave the hole open.

> b) How do you want to signal an error on a *response*?

Good point. In haproxy we return a 502 bad gateway when the server
returns something unparsable. Only the client receives it and (in
rare occasions) reports it.

> ages, so the intermediary ought to be fixed.

I had never heard about %-encoding in header fields to be honnest,
and I don't know which servers or intermediaries decode them given
that unless I'm mistaken, "%" is a valid character in a header field
and doesn't imply %-encoding.

> I think that depends on the header field it is used in.

That can become delicate.

> For instance, 

Indeed, I wasn't aware of this. And it uses the same syntax as in
your proposal.

> It already is, and has been for a long time.

It's just that I never heard about this.

I really think that in the future we should make better use of the
8bit-clean path of HTTP/2 to avoid having to repeat such exceptions,
but I'm sure we'll have to go a long way before reaching this stage :-/

Thanks,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Apr 2015 21:40:22 +0200

> already used as a de-facto standard maybe ?

The major differences would be:

- remove ISO-8859-1 from the set of required encodings, and

- better integration with the httpbis specs.

> n any header field might seem overkill at first glance.

It's an optional encoding; it only applies to those parameter fields 
where the spec explicitly allows it (such as Content-Disposition).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Apr 2015 21:44:45 +0200

> by not specifying the control, we can leave the hole open.

I don't think that there *is* a hole.

> rare occasions) reports it.

For Content-Disposition, this would likely break things that "work" 
today (for some value of "work").

> and doesn't imply %-encoding.

You may want to re-read the spec. It only applies to specific parameter 
names ending in "*".

> That can become delicate.

It doesn't seem to be a problem today.

> Indeed, I wasn't aware of this. And it uses the same syntax as in

It uses the encoding defined in RFC 5987, and that's the spec we would 
be revising here.

> but I'm sure we'll have to go a long way before reaching this stage :-/

I agree, but that's a completely orthogonal project.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Apr 2015 21:50:17 +0200

> today (for some value of "work").

Yes I understand after seeing the RFC6266 you pointed.

> You may want to re-read the spec. It only applies to specific parameter 

I didn't understand that "*" was part of the name but I understood it
as one delimiter to indicate an alternate encoding. Thus I agree that
it is different and limited in scope because it implies that the other
end has to explicitly consume thus name.

(...)
> It uses the encoding defined in RFC 5987, and that's the spec we would 

Thanks for the explanations. I'd say I don't like much what it looks
like, but if you're reusing something that was already in use, at
least it's better than having to support another extra special case.

Thanks,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 1 Apr 2015 21:52:40 +0200

> - better integration with the httpbis specs.

OK thank you very much for the quick diff, that's clear to me now.
Then I don't see anything to argue against from my point of view.

Best regards,
Willy