Fwd: Content-Type is turned to lower when passed through mod_jk - this looks to be a bug.

[Mark O'Donohue <ma...@gmail.com>]

Hi

Just wanted an opinion on this before I logged a bug report against mod_jk.c


Running our proxied request via mod_jk we are seeing the returned content-type
being changing to all lowercase:

eg:

  Content-Type: application/xxx.yyyy.dddd+*JSON*; charset=utf-8

to:

  Content-Type: application/xxx.yyyy.dddd+*json*; charset=utf-8


We thought this was tomcat at first, but turns out to be mod_jk.c that is
the cause :

http://svn.apache.org/repos/asf/tomcat/jk/trunk/native/apache-2.0/mod_jk.c



*for* *(*h *=* 0*;* h *<* num_of_headers*;* h*++)* *{*

        *if* *(!*strcasecmp*(*header_names*[*h*],* "Content-type"*))* *{*

            char ***tmp *=* apr_pstrdup*(*r*->*pool*,* header_values*[*h
*]);*

            ap_content_type_tolower*(*tmp*);*

            /* It should be done like this in Apache 2.0 */

            /* This way, Apache 2.0 will be able to set the output filter */

            /* and it make jk useable with deflate using */

            /* AddOutputFilterByType DEFLATE text/html */

            ap_set_content_type*(*r*,* tmp*);*

        *}*



Now on the validity of upper vs lower - it seems a little bit of a grey
area:

https://www.w3.org/Protocols/rfc1341/4_Content-Type.html



The type, subtype, and parameter names are not case sensitive. For example,
TEXT, Text, and TeXt are all equivalent. Parameter values are normally case
sensitive, but certain parameters are interpreted to be case- insensitive,
depending on the intended use. (For example, multipart boundaries are
case-sensitive, but the "access- type" for message/External-body is not
case-sensitive.)





But as a proxy we dont have an opinion - we just want to pass on what we
get !


Also if we run the request via mod_proxy/*mod_proxy_ajp.c* instead then the
returned content-type header is *not *changed.

So should I open a bug against mod_jk for it?


Cheers - Mark

Re: Fwd: Content-Type is turned to lower when passed through mod_jk - this looks to be a bug.

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 10/15/17 6:54 PM, Mark O'Donohue wrote:
> Hi
> 
> Just wanted an opinion on this before I logged a bug report against
> mod_jk.c
> 
> 
> Running our proxied request via mod_jk we are seeing the returned
> content-type being changing to all lowercase:
> 
> eg:
> 
> Content-Type: application/xxx.yyyy.dddd+*JSON*; charset=utf-8
> 
> to:
> 
> Content-Type: application/xxx.yyyy.dddd+*json*; charset=utf-8
> 
> 
> We thought this was tomcat at first, but turns out to be mod_jk.c
> that is the cause :
> 
> http://svn.apache.org/repos/asf/tomcat/jk/trunk/native/apache-2.0/mod_
jk.c
>
> 
> 
> 
> *for* *(*h *=* 0*;* h *<* num_of_headers*;* h*++)* *{*
> 
> *if* *(!*strcasecmp*(*header_names*[*h*],* "Content-type"*))* *{*
> 
> char ***tmp *=* apr_pstrdup*(*r*->*pool*,* header_values*[*h *]);*
> 
> ap_content_type_tolower*(*tmp*);*
> 
> /* It should be done like this in Apache 2.0 */
> 
> /* This way, Apache 2.0 will be able to set the output filter */
> 
> /* and it make jk useable with deflate using */
> 
> /* AddOutputFilterByType DEFLATE text/html */
> 
> ap_set_content_type*(*r*,* tmp*);*
> 
> *}*
> 
> 
> 
> Now on the validity of upper vs lower - it seems a little bit of a
> grey area:
> 
> https://www.w3.org/Protocols/rfc1341/4_Content-Type.html
> 
> 
> 
> The type, subtype, and parameter names are not case sensitive. For
> example, TEXT, Text, and TeXt are all equivalent. Parameter values
> are normally case sensitive, but certain parameters are interpreted
> to be case- insensitive, depending on the intended use. (For
> example, multipart boundaries are case-sensitive, but the "access-
> type" for message/External-body is not case-sensitive.)
> 
> 
> 
> 
> 
> But as a proxy we dont have an opinion - we just want to pass on
> what we get !
> 
> 
> Also if we run the request via mod_proxy/*mod_proxy_ajp.c* instead
> then the returned content-type header is *not *changed.
> 
> So should I open a bug against mod_jk for it?

I think the only bug here is that mod_jk is wasting time rewriting a
header that doesn't need to be modified.

But I see this strictly as a performance problem and not as a
spec-violation.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlno1p8ACgkQHPApP6U8
pFiUPw/+I4tz1k2pHGC5qW+f8e0+A3gEdfu4StL3b9Uwu5ci/eo3L0Z7oe7t2vXp
7ctifUCs8Ns8wGYj5QEwaR/8NKlgCavscG+jMzFdffsmszh+hPjzUa72q0IYKnHU
6Qc25xqj1Ru2/Iz1SV7t13T+t1ctfdE5wnB2RDC53F1ldA54/fwyLf2ActxdMW+K
XEH+9A+q203WriFIP4Ie1qD4M/x/7J57MBjp3dkbspfR2hmwGvESljXBuAKuDw8N
xpOt2bdXbnqNdHpVtOiHQxvyG9n4Vy69+/8Gd/fvpMsWoH/nJOG99xQ3IIsHieUG
ulLtn2Bb4RIgwGXCnV2cK0SCMPKoyYHMoFQ7fPQIbP3lXqhFtHsrYuGkzZ0ylk08
jqmV3e2VlB70Gd0iXUIhKZLEN1oWirUFZU8behhP75DWKWEAqZA1ThFBk9naG1RX
kLPWpVugB5Q1uLZulK34f5rRBmd85qceIYOfz30wNaT5pHfyumb7/MYoKE9l03lp
JcUg/UbG9XgfsQsC/vH/sSzCCFk89wtUgIqi9VjXQ4uomsJiutzmiyPvtVAYpcdI
v7qEFvvyVvXVuhU7xaygyAsLTQq4s/gHJ0Fx11Nx91iOCDwDEKLUkQZ3ZDcgQglI
Qjy4fcxeM4f7legRH7jhccUptzJZovbdOgMM1TCU8tiIIWFE2EQ=
=UpzH
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org