Re: Call for Adoption: draft-reschke-rfc54987bis

On Wed, Apr 01, 2015 at 09:44:45PM +0200, Julian Reschke wrote:
> >>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.
> 
> For Content-Disposition, this would likely break things that "work" 
> today (for some value of "work").

Yes I understand after seeing the RFC6266 you pointed.

> >>>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.
> >
> >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.
> 
> You may want to re-read the spec. It only applies to specific parameter 
> names ending in "*".

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.

(...)
> >>For instance,
> >>RFC 6266 discusses these constraints for the filename parameter.
> >
> >Indeed, I wasn't aware of this. And it uses the same syntax as in
> >your proposal.
> 
> It uses the encoding defined in RFC 5987, and that's the spec we would 
> be revising here.

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

Received on Wednesday, 1 April 2015 19:50:43 UTC