You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dirk-Willem van Gulik <di...@webweaving.org> on 2017/01/20 19:21:50 UTC
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.
Re: rfc7231 - content-md5
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 20 Jan 2017, at 20:49, William A Rowe Jr <wr...@rowe-clan.net> 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
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> On 20 Jan 2017, at 21:13, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Fri, Jan 20, 2017 at 1:49 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>> On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik
>> <di...@webweaving.org> 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
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Jan 20, 2017 at 1:49 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik
> <di...@webweaving.org> 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
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> On 20 Jan 2017, at 20:49, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik
> <di...@webweaving.org> 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
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Jan 20, 2017 at 1:21 PM, Dirk-Willem van Gulik
<di...@webweaving.org> 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.