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
