Re: rfc7231 - content-md5
> On 20 Jan 2017, at 21:13, William A Rowe Jr wrote: > > On Fri, Jan 20, 2017 at 1:49 PM, William A Rowe Jr > wrote: >> On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik >> wrote: >>> RFC 7231 has retired Content-MD5. >>> >>> Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN >>> or INFO and retire it at the next minor release ? > > +1 > >> Removing what, precisely? Content-MD5 headers aren't implemented in trunk. > > Sorry, I missed a -i arg to grep :) > Ah ok - thanks - I was wondering I had been in Amsterdam for too long (which I had - and it involved shops where they do sell coffee). > Yes, the default_handler behavior in trunk/server/core.c can simply be > removed, > along with the core.c ContentDigest directive handling. I think it > should also be > removed from modules/cache/mod_cache.c as it is not a valid entity header. > > The many unset Content-MD5 actions must remain IMO to guard against our > sharing this upstream or downstream. > > The http_core.h core flag content_md5 and values AP_CONTENT_MD5_* > should probably remain until 3.0 to avoid unnecessary API changes. a doxygen > /** @deprecated Unused flag */ against that struct member will help us mop > these > up during any 3.0 review. Dw.
Re: rfc7231 - content-md5
On 20 Jan 2017, at 20:49, William A Rowe Jr wrote: > > Note that https://www.rfc-editor.org/rfc/rfc7616.txt still provides > for MD5 hashed > digest auth keys. So removing this altogether will break mod_auth_digest in a > manner that breaks existing user auth. > > > Note that https://www.rfc-editor.org/rfc/rfc7616.txt still provides > for MD5 hashed > digest auth keys. So removing this altogether will break mod_auth_digest in a > manner that breaks existing user auth. Right - and these need to stay. These are for interoperability reasons - and only affect that. I think I am getting somewhere - currently going to a handful of packages that use ARP and splitting things into: apr_digest_64() apr_digest_128() apr_digest_256() apr_digest_512() for places where the is no cryptographic need and apr_crypto_digest --- with the actual name of a cryptographic algorithm like SHA256, etc. Either because it has a cryptographic need -or- because of interoperability -or- both. And that seems to yield fairly clean results - which ultimately are conductive to 'fips' style flags to 'force' ancient algorithms, like MD5, to be not in critical places; while letting harmless continue. Dw
Re: rfc7231 - content-md5
> On 20 Jan 2017, at 20:49, William A Rowe Jr wrote: > > On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik > wrote: >> RFC 7231 has retired Content-MD5. >> >> Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN >> or INFO and retire it at the next minor release ? > > Removing what, precisely? Content-MD5 headers aren't implemented in trunk. That is odd. I have in Repository Root: http://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1779019 Quite a few: > ./modules/cache/mod_cache.c:"Content-MD5", > ./modules/filters/mod_brotli.c:apr_table_unset(r->headers_out, > "Content-MD5"); > ./modules/filters/mod_deflate.c:apr_table_unset(r->headers_out, > "Content-MD5"); > ./modules/filters/mod_deflate.c: > apr_table_unset(r->headers_in, "Content-MD5"); > ./modules/filters/mod_deflate.c:apr_table_unset(r->headers_out, > "Content-MD5"); > ./modules/filters/mod_filter.c: > apr_table_unset(r->headers_out, "Content-MD5"); > ./modules/lua/mod_lua.c:apr_table_unset(r->headers_out, > "Content-MD5"); > ./server/core.c:apr_table_setn(r->headers_out, "Content-MD5", > ./server/protocol.c:apr_table_unset(rnew->headers_in, "Content-MD5"); Did I fuck up my repo in an epic way? Dw
Re: rfc7231 - content-md5
On Fri, Jan 20, 2017 at 1:49 PM, William A Rowe Jr wrote: > On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik > wrote: >> RFC 7231 has retired Content-MD5. >> >> Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN >> or INFO and retire it at the next minor release ? +1 > Removing what, precisely? Content-MD5 headers aren't implemented in trunk. Sorry, I missed a -i arg to grep :) Yes, the default_handler behavior in trunk/server/core.c can simply be removed, along with the core.c ContentDigest directive handling. I think it should also be removed from modules/cache/mod_cache.c as it is not a valid entity header. The many unset Content-MD5 actions must remain IMO to guard against our sharing this upstream or downstream. The http_core.h core flag content_md5 and values AP_CONTENT_MD5_* should probably remain until 3.0 to avoid unnecessary API changes. a doxygen /** @deprecated Unused flag */ against that struct member will help us mop these up during any 3.0 review.
Re: rfc7231 - content-md5
On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik wrote: > RFC 7231 has retired Content-MD5. > > Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN > or INFO and retire it at the next minor release ? Removing what, precisely? Content-MD5 headers aren't implemented in trunk. Note that https://www.rfc-editor.org/rfc/rfc7616.txt still provides for MD5 hashed digest auth keys. So removing this altogether will break mod_auth_digest in a manner that breaks existing user auth.
rfc7231 - content-md5
RFC 7231 has retired Content-MD5. Fair game to remove it from -trunk - or make it squeek 'debrecated' at WARN or INFO and retire it at the next minor release ? Dw.