Another session problem

[Edi Weitz]

The URL rewrite code should treate <A HREF ...> exactly like <FORM
ACTION ...> (and that seems to work, at least for me).  Is something
else in your code (or maybe on the client side, with Javascript)
manipulating the content?

On Thu, Mar 20, 2014 at 9:22 AM, Nicolas Neuss <neuss at scipolis.de> wrote:
> Hello,
>
> I have the following problem.
>
> Hunchentoot 1.2.26/SBCL 1.0.57 is serving pages from behind Apache.
> More precisely, my Apache config is
>
> <VirtualHost *:80>
>         ServerAdmin neuss at scipolis.de
>         ServerName yyy.math.fau.de
>         ServerAlias yyy.math.fau.de
>
>         DocumentRoot /var/www
>         <Directory />
>                 Options FollowSymLinks
>                 AllowOverride None
>         </Directory>
>         <Directory /var/www/>
>                 Options FollowSymLinks MultiViews
>                 AllowOverride None
>                 Order allow,deny
>                 allow from all
>         </Directory>
>
>         ErrorLog ${APACHE_LOG_DIR}/error.log
>         ErrorDocument 404 /index.html
>
>         ProxyRequests     Off
>         ProxyPass /wissen http://localhost:8002
>         ProxyPassReverse /wissen http://localhost:8002
> </VirtualHost>
>
> Now when accessing the page
>
>   <http://yyy.math.fau.de/wissen/admin-login?nr=4>
>
> for the first time (!), the "form" gets an additional "action" parameter
> which is an absolute path like
>
> <form method=post action='/admin-login?nr=4&hunchentoot-session=17997%3A98C123D51D88E2BDBD28DC2E00D16E42'>
>
> while "href"s are (correctly) relative like
> <a href='about?hunchentoot-session=17997%3A98C123D51D88E2BDBD28DC2E00D16E42'>Informationen</a>
>
> This leads to a wrong redirection when submitting the form.
>
> Is this a bug or is anything wrong with my setup?
>
> I'm using Hunchentoot 1.2.26 from Quicklisp.
>
> Thank you,
>
> Nicolas
>
> P.S.: If one refreshes the page after first access the action parameter
> goes away and everything works as desired.  Also with redirecting to the
> login page I can remove this behaviour, but I would like to
> understand what is going on here.
>