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@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.
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@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@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.
Edi Weitz <edi@agharta.de> writes:
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?
Hi Edi, does that means that if you access my URL http://yyy.math.fau.de/wissen/admin-login?nr=4 for the first time, the downloaded page source contains a line like <form method=post action='admin-login?nr=4&hunchentoot-session=...'> instead of <form method=post action='/admin-login?nr=4&hunchentoot-session=...'> ^ ! ?? Thanks for the feedback, Nicolas
The only difference I can see in your email is the slash. That's something that shouldn't be affected by URL rewriting at all. I'm attaching the HTML page I received when I viewed your URL for the first time (using Firefox). On Thu, Mar 20, 2014 at 10:16 AM, Nicolas Neuss <neuss@scipolis.de> wrote:
Edi Weitz <edi@agharta.de> writes:
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?
Hi Edi,
does that means that if you access my URL
http://yyy.math.fau.de/wissen/admin-login?nr=4
for the first time, the downloaded page source contains a line like
<form method=post action='admin-login?nr=4&hunchentoot-session=...'>
instead of
<form method=post action='/admin-login?nr=4&hunchentoot-session=...'> ^ !
??
Thanks for the feedback,
Nicolas
Somehow the slash is the problem, because it is interpreted (at least my Firefox does it, as well as my Konqueror) as
instead of
while the link without the slash is interpreted as desired. It is very unclear to me which software is to blame. More precisely, I see the following possibilities: 1. The Apache proxy module for not translating the absolute path starting with slash correctly into a path containing '.../wissen/...' 2. My configuration of that module: ... ProxyRequests Off ProxyPass /wissen http://localhost:8002 ProxyPassReverse /wissen http://localhost:8002 ... 3. Whatever code inserts the "action" parameter in the first place. (I don't have this "action" in my template, which is processed by HTML-TEMPLATE, URL-REWRITE, HUNCHENTOOT, ...) Thanks, Nicolas Edi Weitz <edi@agharta.de> writes:
The only difference I can see in your email is the slash. That's something that shouldn't be affected by URL rewriting at all.
I'm attaching the HTML page I received when I viewed your URL for the first time (using Firefox).
On Thu, Mar 20, 2014 at 10:16 AM, Nicolas Neuss <neuss@scipolis.de> wrote:
Edi Weitz <edi@agharta.de> writes:
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?
Hi Edi,
does that means that if you access my URL
http://yyy.math.fau.de/wissen/admin-login?nr=4
for the first time, the downloaded page source contains a line like
<form method=post action='admin-login?nr=4&hunchentoot-session=...'>
instead of
<form method=post action='/admin-login?nr=4&hunchentoot-session=...'> ^ !
??
Thanks for the feedback,
Nicolas
-- Nicolas Neuss neuss@math.fau.de
On Thu, Mar 20, 2014 at 11:51 AM, Nicolas Neuss <neuss@scipolis.de> wrote:
ProxyRequests Off ProxyPass /wissen http://localhost:8002 ProxyPassReverse /wissen http://localhost:8002
I'd replace /wissen with /wissen/ and :8002 with :8002/ in both cases. That's what I do in my apps. (But then URLs ending in ".../wissen" won't work anymore if that's a problem for you. (Which you could in turn fix with mod_rewrite, hehe...)) Otherwise, as Hans already said, set *REWRITE-FOR-SESSION-URLS* to NIL if you don't need cookie-less sessions. That would be two possible sources for errors. (And, yes, Hunchentoot indeed adds the ACTION parameter. This behavior is controlled by url-rewrite:*url-rewrite-fill-tags* but you won't see it anymore if you set the variable mentioned above to NIL.)
Edi Weitz <edi@agharta.de> writes:
On Thu, Mar 20, 2014 at 11:51 AM, Nicolas Neuss <neuss@scipolis.de> wrote:
ProxyRequests Off ProxyPass /wissen http://localhost:8002 ProxyPassReverse /wissen http://localhost:8002
I'd replace /wissen with /wissen/ and :8002 with :8002/ in both cases. That's what I do in my apps. (But then URLs ending in ".../wissen" won't work anymore if that's a problem for you. (Which you could in turn fix with mod_rewrite, hehe...))
I tried this just now. However, the behavior stayed the same, so I reverted that change.
Otherwise, as Hans already said, set *REWRITE-FOR-SESSION-URLS* to NIL if you don't need cookie-less sessions.
Yes, this helps. Thank you (and thank you Hans).
That would be two possible sources for errors.
(And, yes, Hunchentoot indeed adds the ACTION parameter. This behavior is controlled by url-rewrite:*url-rewrite-fill-tags* but you won't see it anymore if you set the variable mentioned above to NIL.)
OK. Of course, I would prefer to have it working also for those who forbid cookies. But I guess that there won't be many such people nowadays. [I had found the *url-rewrite-fill-tags* and the place where it was used in url-rewrite.lisp already. But the code following is quite opaque to me, i.e. I didn't yet see where the slashed value '/admin-login?nr=4&hunchentoot-session=17997%3A98C123D51D88E2BDBD28DC2E00D16E42' for the "action" parameter which I mentioned in my previous post is generated. Now I think I found it: it is (REQUEST-URI *REQUEST*) in the function ADD-COOKIE-VALUE-TO-URL in hunchentoot/misc.lisp.] Nicolas P.S.: It's 5 am here. I could not sleep so I looked at this again, but now I'll try to take another nap until I really have to get up.
Hi Nicolas, what you're seeing is Hunchentoot rewriting the contents of forms so that a session ID parameter is automagically added to forms for clients that do not have cookies enabled. The documentation mentions that this is done unless *rewrite-for-session-urls* is NIL. I am not sure whether the functionality is working all that well, as I have not been using it in the past. If you do not need to support sessions without cookies, I'd recommend that you disable the functionality. If you do need it, it would be helpful if you could debug some more to pinpoint where the behavior is actually wrong. Thanks, Hans 2014-03-20 9:22 GMT+01:00 Nicolas Neuss <neuss@scipolis.de>:
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@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.
On Thu, Mar 20, 2014 at 9:43 AM, Hans Hübner <hans.huebner@gmail.com> wrote:
I am not sure whether the functionality is working all that well
It works fine. Here's an app that is used by my students almost every day: http://weitz.de/mars/ Click on the link above and look at the source code. You should see that the <FORM ACTION ...> part is properly rewritten. Cheers, Edi.
2014-03-20 9:48 GMT+01:00 Edi Weitz <edi@agharta.de>:
On Thu, Mar 20, 2014 at 9:43 AM, Hans Hübner <hans.huebner@gmail.com> wrote:
I am not sure whether the functionality is working all that well
It works fine. Here's an app that is used by my students almost every day:
Click on the link above and look at the source code. You should see that the <FORM ACTION ...> part is properly rewritten.
No offense intended - I just don´t use it, and I would avoid content rewriting in most circumstances. -Hans
participants (3)
-
Edi Weitz -
Hans Hübner -
Nicolas Neuss