Space in task attachment name

[NW987]

In ES2, it appears that attachments that contain spaces in the file name will fail to open.  Is this a bug?  Is it covered in the release notes or other docs?

[Robert_Haché]

Is there any more information you can provide?  We are not able to reproduce this problem.

What type of attachment are you using?  PDF?  Word doc?  Text File?  Also is this a customized Workspace or out of the box?

Are you seeing this right after you add an attachment or is the problem when you open the task at the next step?  What permissions are you applying to the attachment?

Thanks,

[NW987]

It's a PDF attachment with the out of the box workspace.

If I use a file attachment with the name "nickform1.pdf", the attachment opens fine.  If I use an attachment name "nick form1.pdf", the attachment does not open.

When using an attachment with a space in the filename, the URL the form is looking for is https://<servername>/workspace-server/documents/3363251748108822060-47/nick%20form1.pdf, which appears to be correct. 

If I manually remove the %20 from the browser URL bar, the attachment does open.  So it appears livecycle is stripping the spaces from the attachment file name? 

We are also using an apache proxy so I'm not sure if that's related.  This process/attachment works fine prior to the ES2 upgrade.

[Robert_Haché]

Thanks for the info.  You mention you've upgraded to ES2, are you at SP1 or just ES2 GM?

Also are you able to try the non-ssl port?  I still can't reproduce the problem but I'm tracking down an ES2 server.  I've tried ES3 and ES2 SP1.

Thanks for your patience,

[NW987]

Thanks.   I'm using ES2 SP2.

It's odd.  When I manipulate the port # in the attachment URL to go directly to jboss(without the Apache proxy), I'm also able to retrieve the attachment.  So the original problem remains, but the two work around combinations that I've found are:

https://<servername>:<jbossport>/workspace-server/documents/3363251748108822060-47 /nick%20form1.pdf

https://<servername>/workspace-server/documents/3363251748108822060-47 /nickform1.pdf

[Robert_Haché]

I am now using an Apache proxy server, with ssl enable, to talk to an ES2 SP2 server and am still, unfortunately, unable to reproduce the problem.

Here is the URL that my attachment gets:

https://<server>/workspace-server/documents/-1298210021392754748-12/PDF17%20Form.pdf

I find it curious that the url works when you remove the %20 in the name.  I would have expected a file not found error because it would then be looking for

'nickform1' when it should be looking for 'nick form1'.

I'm using I.E. 7, I.E. 8, I.E. 9 and Safari 3.6.12.

[Robert_Haché]

One more thought/question.

You say the attachment displays correctly when you do not use the proxy server.  That may point to a problem with your proxy server.  Can you look in the log files for your proxy server and see if any errors are written there?

[NW987]

Thanks for the help so far, I'm  taking another look at this.  It's clear at this point that the problem is related to the Apache<->JBoss configuration.

Are you using mod_jk, or mod_proxy in your Apache configuration?  Either way, would you be able to share the relevant snippet from you http.conf or ssl.conf?

It appears from my research that the noncanon option of mod_proxy is part of the solution, but I'm having trouble getting the exact combination.  The original configuration that I used is http://blogs.adobe.com/livecycle/2009/04/fronting_livecyclejboss_with_a.html. Thanks.

[Robert_Haché]

We are using mod_proxy.  I did not make any changes to the mod_rewrite (as suggested in the blog you linked to).  I merely modified the httpd.conf file to enable the reverse proxy as well as ssl by uncommenting the applicable settings (as mentioned in the blog you linked to). 

I then added the following info to the bottom of the httpd.conf file:

ProxyRequests OFF
<Proxy *>
Order deny,allow
Allow from all
</Proxy>

ProxyPass / http://>server>:8080/
ProxyPassReverse / http://<server>:8080/

I found the <nocanon> option in the mod_proxy.html.en file but I did not make any changes there so am using the defaults.

I don't imagine that helps you much but the only files I modifed were the httpd.conf file and the httpd-ssl.conf file.

[NW987]

Thanks for the help in this, I was able to find the cause.  The siteminder apache module has a badurlchars parameter that was apparently configured to deny any requests containing space(I have no idea why).  The configuration issue was not observed until the upgrade to ES2 and the change in attachment handling that results.