Bugzilla Bug 6849

URL-encoding them is not always sufficient because some proxies do not keep
things encoded as they should, and we cannot fix all proxies out there...

Created an attachment (id=1065) [details]
proposed function to decode URIs in URL

org.wyona.yanel.core.util.HttpServletRequestHelper seemed to me like a good
home for this.

To solve the bug, this still needs to be called from Yanel servlet.
I intend to make a separate patch later, with HTMLUnit tests as well... but for
these I would need the patches in
http://lists.wyona.org/pipermail/yanel-development/2008-December/002517.html
which would give them a home! ;)

Created an attachment (id=1068) [details]
Yanel servlet patch that uses the previous one to fix the bug

Thanks for commiting the function! Now that this and the other referenced
patches are available, here is the announced patch that finally fixes the bug.
Changes in YanelServlet (in source reverse order):
 - we now use the decoding function result (when necessary)
 - fixed minor things I forgot in the previous refactoring
 - also removed unused imports
Added more tests for this as well.

commited patch
http://bugzilla.wyona.com/cgi-bin/bugzilla/attachment.cgi?id=1068&action=view
in r40436

now there is a problem with the global data when deploying yanel in the ROOT
context.

Can you explain a bit?

Also we need to add a Hudson test which is testing Yanel within the ROOT and
also within some other prefix, e.g. /yaneltest/

Cheers

Michi

OK, so AFAIU Simon is now adding some other custom configurations ATM.

I tested locally and it seems to work. Simon tested again and it also worked
for him: the icons on the main page used not to be there the 1st time.

So we are all waiting for the final answer from Hudson, but anyone feel free to
test it yourself locally and report your findings here!


BTW for the prefix, maybe we should better one that does not start with or end
with or even contain "yanel" like "other-yanl-prefix".

it works on hudson. now we have in hudson a yanel deployed in 'ROOT' context
and in a prefix called 'webapp-prefix'. both is working. son't know yet why it
didn't work for me.

The "PathUtil.getResourcesHtdocsPathURLencoded" method still does not work, and
we have no real setup with an Apache front-end to regression-test this bug!

...proof being revision 44352!

(From update of attachment 1065 [details])
Committed by Simon (see comment #3).

(From update of attachment 1068 [details])
Committed by Simon (see comment 3).

I think in order to use this one needs to set

http://httpd.apache.org/docs/2.0/mod/core.html#allowencodedslashes

e.g.

<VirtualHost 195.226.6.73:80>
    ServerAdmin michael.wechner@wyona.com
    ServerName www.wyonapictures.com
    ServerAlias wyonapictures.com wyona-pictures.com
    ErrorLog logs/www.wyonapictures.com-error_log
    CustomLog logs/www.wyonapictures.com-access_log common

    AllowEncodedSlashes On
    ProxyPassReverseCookiePath /ulysses /

    <Proxy balancer://mycluster>
      BalancerMember http://127.0.0.1:8190
      BalancerMember http://127.0.0.1:8290
    </Proxy>
    ProxyPass           /  balancer://mycluster/yanel/wyona-pictures/
    ProxyPassReverse    /  balancer://mycluster/yanel/wyona-pictures/
</VirtualHost>

(In reply to comment #8)
> The "PathUtil.getResourcesHtdocsPathURLencoded" method still does not work, and
> we have no real setup with an Apache front-end to regression-test this bug!

Testing Wyona's website using Wyona's Linux Hudson offers such a setup, and we
already tested the decode functionality using it, so probably we can find
another usecase exercising the encoding.


(In reply to comment #12)
> I think in order to use this one needs to set
> 
> http://httpd.apache.org/docs/2.0/mod/core.html#allowencodedslashes
> 
> e.g. [...]

http://lists.wyona.org/pipermail/yanel-development/2009-December/004193.html
discusses this further.