mod_jk and webdav

[toltech]

L.S.,
We want to use mod_jk to shield off the tomcat server and let apache redirect requests. Evering seems to be working except for the webdav part. Strange enough mod_jk gives back a "Content-Type: text/plain; charset=iso-8859-1" header. If we access tomcat directly this does not happen.

The result is that the web browser does not display the page as html, but as plain text. Does anyone know a way to prevent this?

Below are the server responses of both requests.

mod_jk:
http://admin:*password*@apacheserver/alfresco/webdav
           => `webdav.4'
  HTTP/1.1 200 OK
  Date: Sun, 16 Sep 2007 16:20:46 GMT
  Server: Apache/1.3.34 (Ubuntu) mod_jk/1.2.25 PHP/4.4.2-1build1
  Set-Cookie: JSESSIONID=71A9B6DE98348C07383EB18E80256F1C; Path=/alfresco
  Connection: close
  Content-Type: text/plain; charset=iso-8859-1
  X-Pad: avoid browser bug
Length: unspecified [text/plain]

direct:
http://admin:*password*@tomcat:8080/alfresco/webdav
  HTTP/1.1 200 OK
  Server: Apache-Coyote/1.1
  Set-Cookie: JSESSIONID=6B48201FBBAD898B282AD43E1C1872E1; Path=/alfresco
  Date: Sun, 16 Sep 2007 16:20:34 GMT
  Connection: close
Length: unspecified

[toltech]

Further analysis shows that if the /alfresco/webdav/ gives back the right content type ( Content-Type: text/html;charset=UTF-8 ) the problem will be solved. Is there a way to do this?

[toltech]

To be more precise: only if the webdav url points at a "space", no content type is being generated. If the content is a pdf or a jpg, the correct content-type is generated hence the browser processes the request correctly through mod_jk.

In the webdav interface, a space always points at a html page therefore the content type should be text/html. In the entire process where the client uses mod_jk through apache, in the absence of a content-type header, somewhere in the chain, the wrong content-type is added automatically (text/plain). This leads to the page not being displayed as an html page.

Should I report this as a bug?

[kevinr]

I know there was a bug fixed in this area - webdav pages were not outputing the content type. I think it was fixed for 2.1 - are you using 2.0?

Thanks,

Kevin

[jpotts]

Kevin, can you point me to a Jira issue number?

I'm seeing this problem on 2.1.1 Enterprise.

To re-cap the problem:
- Web client can upload files with international characters as file names without a problem
- File names uploaded via webdav get mangled

I have confirmed that if I remove Apache from the equation and hit WebDAV on port 8080 directly, the problem goes away. Going through Apache via mod_jk, with or without SSL, causes the problem.

Config:
- Red Hat Enterprise Linux 4 (2.6.9-55.0.2.ELsmp)
- Apache 2.0.52 with mod_jk, mod_rewrite, and mod_ssl
- Alfresco-Tomcat bundle 2.1.1 Enterprise
- MySQL 4.1.20 with UTF-8 across the board
- URIEncoding attribute set properly in Connector tags within server.xml
- JDK 1.5.0_14

Going through Apache with and without SSL works fine on Ubuntu Gutsy. But on Gutsy, I'm running Apache 2.2.4 and JDK 1.5.0_13..

Jeff

[jpotts]

Peter over at Alfresco Support found the answer. When using mod_jk, in addition to making sure each of the <Connector /> tags in server.xml has the URIEncoding="UTF-8" set, you have to add the following jkOptions parm to your httpd.conf (or your alfresco.conf or whatever included apache conf file you want):

JkOptions +ForwardURICompatUnparsed‍

Here's the link with the info:
http://confluence.atlassian.com/display/DOC/Configuring+Tomcat%27s+URI+encoding

[jpotts]

If you are also using mod_rewrite, for example to rewrite "/" to "/alfresco/" the use of ForwardURICompatUnparsed will break the rewrite rule. We haven't settled on a workaround yet. I'll edit this post when we do.