On 5 June 2014 13:02, Greg Wilkins <gregw@intalio.com> wrote: > Regarding padding: I don't quite understand the argument against allowing > it in the spec. If the h2 library's API makes frame padding options > available to the application, then the application, which has more chance > of knowing things like the provenance and value of the bytes, can choose to > obfuscate them. If the application doesn't use padding, or does so > improperly, does that count as a security failing of HTTP/2? Is it better > to make everyone never pad at this level? Having the padding in the spec is not that much of an intrusion, but I just don't see what good it does. If an application wants to pad it's data for security reason, then it does not need a transport mechanism for that. The only reason the transport needs to be aware of padding is if the transport is expected to do something with it - ie like generate it. But as the warnings in the draft clearly make out, generating padding is apparently non trivial and should only be done by experts with detailed knowledge of the actual payload. So if the transport is not going to generate the padding, not handle the padding, etc. then why does the transport even need to know about the padding? To me it is setting false expectation that the implementation of h2 will be safe from leaking information about their meta data and payloads. cheers -- Greg Wilkins <gregw@intalio.com> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Received on Thursday, 5 June 2014 11:10:28 UTC