Re: [Stripes-users] Clean URLs failing on form post
William,
Sure, you could definitely come up with many ways to hit this particular
issue... and I won't refute that... . In fact, I wasn't even aware of it
in the 1st place and I Thank You for sharing it with the community.
But, again I would never see it because any web app I build
essentially has WebRoot that looks like this:
/css
/img
/js
/WEB-INF
Not sure if this is explicit best practice but if it isn't it sure might
be implicit best practice as many a web app are built this way.
ASIDE: I say essentially b/c we in fact have a structure that starts
with /static/__ID/[css|img|js] and when we release __ID is the release
version and we set the expires for everything under /static to 1 year
and we will run it through a CDN... but that is all another story
altogether and I guess the only worry I could have is if I had a URL
binding that started with /static/ so thanks for the heads up... .
So in your case I would have:
/images
/jobs
/add-icon.png
/del-icon.png
/css
/edit.css
/WEB-INF
/jsp
/jobs
/edit.jsp
/list.jsp
And there are NUMEROUS intrinsic design benefits here as:
- you get fewer top level folders... easier to manage... yes you could
make the argument that having things dissected by business area /
ActionBean is easier to manage but I think if you try this you might see
what I am talking about... .
- all your images, css and js are rooted under 1 respective folder and
easily zipped, replaced, scanned, etc...
- do you really have a different edit.css file for different business
areas / ActionBeans?
- when / if you add JS do you really have a different JS file for
different business areas / ActionBeans?
- having fewer css / JS files takes advantage of web browser caching,
limits the cost of the network trip hit, etc...
- and I can go on and on... but now we are talking about Application
Design... and grey areas... and are off topic... .
Does this not address your problem / the bug you found?
--Nikolaos
Rose William wrote:
Hi Nikolaos,
It probably is!
In my case, the only thing in my folder structure was JSPs, so moving
them to some other folder structure would fix the issue.
More generally, though, I thought that part of the magic of
DynamicMappingFilter was supposed to be that one could have one's action
beans appearing to share the same folders as their resources (e.g. CSS,
JS, images) and so it ought not matter that the JSPs were there too.
Let's say I rearranged my JSPs, but also added some extra graphics and
stylesheets:
/jobs
/images
/add-icon.png
/del-icon.png
/css
/edit.css
/WEB-INF
/jsp
/jobs
/edit.jsp
/list.jsp
I still have the same problem with Tomcat adding a / to
/contextPath/jobs, despite following best practice for placement of
JSPs.
Kind regards,
William Rose
Business Intelligence Team Leader
Information Management
+61 3 9656 5231 | Level 8, St Andrews Place, East Melbourne VIC 3002
-Original Message-
From: Nikolaos Giannopoulos [mailto:nikol...@brightminds.org]
Sent: Thursday, 3 February 2011 2:11 PM
To: Stripes Users List
Subject: Re: [Stripes-users] Clean URLs failing on form post
William,
Isn't it best practice to place ones JSPs rooted under /WEB-INF. This
ensures that your JSPs are never directly accessible from the outside
while still allowing your ActionBean's to forward to them.
If you followed this then Tomcat nor any other Web Container would
succeed in placing a slash and matching your JSP structure.
Or am I missing something...?
--Nikoloas
Rose William wrote:
Hi there,
I found the recent discussion on the mailing list about clean URLs
seemingly failing to find the right event handler when a form is
POSTed, and saw a variety of solutions to creating the URL oneself.
After trying to debug the same issue myself, I think the reason for
this behaviour is tied up in Tomcat bug 32424 (see
https://issues.apache.org/bugzilla/show_bug.cgi?id=32424).
My web app is set up with DynamicMappingFilter applied to /*.
I have a WEB directory structure like this:
/jobs
/edit.jsp
/list.jsp
I have an action bean annotated like this:
@UrlBinding(/jobs/{$event}/{fullName})
There is a list event, new event and save event:
//@DefaultHandler
@DontBind
@HandlesEvent(list)
public Resolution list() throws SchedulerException {
s_log.debug(in list());
return new ForwardResolution(/jobs/list.jsp);
}
@HandlesEvent(new)
@DontValidate
public Resolution newJob() throws SchedulerException {
s_log.debug(in newJob());
return new ForwardResolution(/jobs/edit.jsp);
}
@HandlesEvent(save)
public Resolution saveJob() throws SchedulerException
Re: [Stripes-users] Clean URLs failing on form post
Hi Nikolaos, Adopting your approach for organising your web resources does work well as a workaround for this issue, and is presumably why it's not a more common problem. I structure my web apps more like you than my last example (except for the placement of JSPs), and I've now popped my JSPs under WEB-INF too, so this issue really isn't hurting me any more either. I also took of the @HandleEvent calls as suggested by Sam (I renamed new to create). Things are much smoother now! Kind regards, William Rose From: Nikolaos Giannopoulos [mailto:nikol...@brightminds.org] Sent: Friday, 4 February 2011 2:23 AM To: Stripes Users List Subject: Re: [Stripes-users] Clean URLs failing on form post William, Sure, you could definitely come up with many ways to hit this particular issue... and I won't refute that... . In fact, I wasn't even aware of it in the 1st place and I Thank You for sharing it with the community. But, again I would never see it because any web app I build essentially has WebRoot that looks like this: /css /img /js /WEB-INF Not sure if this is explicit best practice but if it isn't it sure might be implicit best practice as many a web app are built this way. ASIDE: I say essentially b/c we in fact have a structure that starts with /static/__ID/[css|img|js] and when we release __ID is the release version and we set the expires for everything under /static to 1 year and we will run it through a CDN... but that is all another story altogether and I guess the only worry I could have is if I had a URL binding that started with /static/ so thanks for the heads up... . So in your case I would have: /images /jobs /add-icon.png /del-icon.png /css /edit.css /WEB-INF /jsp /jobs /edit.jsp /list.jsp And there are NUMEROUS intrinsic design benefits here as: - you get fewer top level folders... easier to manage... yes you could make the argument that having things dissected by business area / ActionBean is easier to manage but I think if you try this you might see what I am talking about... . - all your images, css and js are rooted under 1 respective folder and easily zipped, replaced, scanned, etc... - do you really have a different edit.css file for different business areas / ActionBeans? - when / if you add JS do you really have a different JS file for different business areas / ActionBeans? - having fewer css / JS files takes advantage of web browser caching, limits the cost of the network trip hit, etc... - and I can go on and on... but now we are talking about Application Design... and grey areas... and are off topic... . Does this not address your problem / the bug you found? --Nikolaos Rose William wrote: Hi Nikolaos, It probably is! In my case, the only thing in my folder structure was JSPs, so moving them to some other folder structure would fix the issue. More generally, though, I thought that part of the magic of DynamicMappingFilter was supposed to be that one could have one's action beans appearing to share the same folders as their resources (e.g. CSS, JS, images) and so it ought not matter that the JSPs were there too. Let's say I rearranged my JSPs, but also added some extra graphics and stylesheets: /jobs /images /add-icon.png /del-icon.png /css /edit.css /WEB-INF /jsp /jobs /edit.jsp /list.jsp I still have the same problem with Tomcat adding a / to /contextPath/jobs, despite following best practice for placement of JSPs. Kind regards, William Rose Business Intelligence Team Leader Information Management +61 3 9656 5231 | Level 8, St Andrews Place, East Melbourne VIC 3002 -Original Message- From: Nikolaos Giannopoulos [mailto:nikol...@brightminds.org] Sent: Thursday, 3 February 2011 2:11 PM To: Stripes Users List Subject: Re: [Stripes-users] Clean URLs failing on form post William, Isn't it best practice to place ones JSPs rooted under /WEB-INF. This ensures that your JSPs are never directly accessible from the outside while still allowing your ActionBean's to forward to them. If you followed this then Tomcat nor any other Web Container would succeed in placing a slash and matching your JSP structure. Or am I missing something...? --Nikoloas Rose William wrote: Hi
[Stripes-users] Clean URLs failing on form post
Hi there,
I found the recent discussion on the mailing list about clean URLs
seemingly failing to find the right event handler when a form is POSTed,
and saw a variety of solutions to creating the URL oneself.
After trying to debug the same issue myself, I think the reason for this
behaviour is tied up in Tomcat bug 32424 (see
https://issues.apache.org/bugzilla/show_bug.cgi?id=32424).
My web app is set up with DynamicMappingFilter applied to /*.
I have a WEB directory structure like this:
/jobs
/edit.jsp
/list.jsp
I have an action bean annotated like this:
@UrlBinding(/jobs/{$event}/{fullName})
There is a list event, new event and save event:
//@DefaultHandler
@DontBind
@HandlesEvent(list)
public Resolution list() throws SchedulerException {
s_log.debug(in list());
return new ForwardResolution(/jobs/list.jsp);
}
@HandlesEvent(new)
@DontValidate
public Resolution newJob() throws SchedulerException {
s_log.debug(in newJob());
return new ForwardResolution(/jobs/edit.jsp);
}
@HandlesEvent(save)
public Resolution saveJob() throws SchedulerException {
return new RedirectResolution(JobAction.class,
edit).addParameter(fullName, this.jobDetail.getFullName());
}
In edit.jsp, I have a form like this:
stripes:form name=jobEdit id=jobEditForm
beanclass=myorg.action.JobAction
[form fields]
stripes:submit name=save value=Save /
/stripes:form
What happens is that when the page is rendered, I get HTML like:
form id=jobEditForm name=jobEdit action=/contextPath/jobs
method=post
The important thing to note here is that /contextPath/jobs resolves to a
folder -- the one that contains edit.jsp and possibly other resources.
Ostensibly, DynamicMappingFilter caters for such things because it waits
until the request 404's before handling it. And when a link is
constructed or a form submitted using GET, everything is just fine.
The problem is that Tomcat, as per the bug above, sees that
/contextPath/jobs is a folder early in the processing of the POSTed form
and issues a redirect to /contextPath/jobs/. This happens means all the
POST data is dropped and a GET request to /contextPath/jobs/ with no
extra parameters is issued.
Hence, Stripes will complain with errors like No default handler could
be found for ActionBean, or just show the default handler for that
action bean (in my case, if I uncommented the @DefaultHandler
annotation, I would always see the job list).
I think that this is why fixes proposed in the recent thread that
involved creating the URL differently would end up working -- in the
end, those URLs would be terminated with a slash, or at least would not
end up looking like a known directory to Tomcat. Other web containers
may do the same thing.
So a potential fix for Stripes to work around the fact that Tomcat devs
consider this not a bug is to have the form tag pop a / at the end of
beanclass based URLs when the method is POST (?).
My workaround is to make my URL patterns not overlap with actual folders
-- changing jobs to job in @UrlBinding(/job/{$event}/{fullName}) --
means that the post URL is /contextPath/job, and Tomcat doesn't mess
with it.
I hope this helps someone avoid spending their morning trying to figure
out why their by-the-book clean URL is not working!
Kind regards,
William Rose
This email (including any attachments or links) may contain
confidential and/or legally privileged information and is
intended only to be read or used by the addressee. If you
are not the intended addressee, any use, distribution,
disclosure or copying of this email is strictly
prohibited.
Confidentiality and legal privilege attached to this email
(including any attachments) are not waived or lost by
reason of its mistaken delivery to you.
If you have received this email in error, please delete it
and notify us immediately by telephone or email. Peter
MacCallum Cancer Centre provides no guarantee that this
transmission is free of virus or that it has not been
intercepted or altered and will not be liable for any delay
in its receipt.
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Clean URLs failing on form post
Hi Nikolaos,
It probably is!
In my case, the only thing in my folder structure was JSPs, so moving
them to some other folder structure would fix the issue.
More generally, though, I thought that part of the magic of
DynamicMappingFilter was supposed to be that one could have one's action
beans appearing to share the same folders as their resources (e.g. CSS,
JS, images) and so it ought not matter that the JSPs were there too.
Let's say I rearranged my JSPs, but also added some extra graphics and
stylesheets:
/jobs
/images
/add-icon.png
/del-icon.png
/css
/edit.css
/WEB-INF
/jsp
/jobs
/edit.jsp
/list.jsp
I still have the same problem with Tomcat adding a / to
/contextPath/jobs, despite following best practice for placement of
JSPs.
Kind regards,
William Rose
Business Intelligence Team Leader
Information Management
+61 3 9656 5231 | Level 8, St Andrews Place, East Melbourne VIC 3002
-Original Message-
From: Nikolaos Giannopoulos [mailto:nikol...@brightminds.org]
Sent: Thursday, 3 February 2011 2:11 PM
To: Stripes Users List
Subject: Re: [Stripes-users] Clean URLs failing on form post
William,
Isn't it best practice to place ones JSPs rooted under /WEB-INF. This
ensures that your JSPs are never directly accessible from the outside
while still allowing your ActionBean's to forward to them.
If you followed this then Tomcat nor any other Web Container would
succeed in placing a slash and matching your JSP structure.
Or am I missing something...?
--Nikoloas
Rose William wrote:
Hi there,
I found the recent discussion on the mailing list about clean URLs
seemingly failing to find the right event handler when a form is
POSTed, and saw a variety of solutions to creating the URL oneself.
After trying to debug the same issue myself, I think the reason for
this behaviour is tied up in Tomcat bug 32424 (see
https://issues.apache.org/bugzilla/show_bug.cgi?id=32424).
My web app is set up with DynamicMappingFilter applied to /*.
I have a WEB directory structure like this:
/jobs
/edit.jsp
/list.jsp
I have an action bean annotated like this:
@UrlBinding(/jobs/{$event}/{fullName})
There is a list event, new event and save event:
//@DefaultHandler
@DontBind
@HandlesEvent(list)
public Resolution list() throws SchedulerException {
s_log.debug(in list());
return new ForwardResolution(/jobs/list.jsp);
}
@HandlesEvent(new)
@DontValidate
public Resolution newJob() throws SchedulerException {
s_log.debug(in newJob());
return new ForwardResolution(/jobs/edit.jsp);
}
@HandlesEvent(save)
public Resolution saveJob() throws SchedulerException {
return new RedirectResolution(JobAction.class,
edit).addParameter(fullName, this.jobDetail.getFullName());
}
In edit.jsp, I have a form like this:
stripes:form name=jobEdit id=jobEditForm
beanclass=myorg.action.JobAction
[form fields]
stripes:submit name=save value=Save /
/stripes:form
What happens is that when the page is rendered, I get HTML like:
form id=jobEditForm name=jobEdit
action=/contextPath/jobs
method=post
The important thing to note here is that /contextPath/jobs resolves to
a folder -- the one that contains edit.jsp and possibly other
resources.
Ostensibly, DynamicMappingFilter caters for such things because it
waits until the request 404's before handling it. And when a link is
constructed or a form submitted using GET, everything is just fine.
The problem is that Tomcat, as per the bug above, sees that
/contextPath/jobs is a folder early in the processing of the POSTed
form and issues a redirect to /contextPath/jobs/. This happens means
all the POST data is dropped and a GET request to /contextPath/jobs/
with no extra parameters is issued.
Hence, Stripes will complain with errors like No default handler
could be found for ActionBean, or just show the default handler for
that action bean (in my case, if I uncommented the @DefaultHandler
annotation, I would always see the job list).
I think that this is why fixes proposed in the recent thread that
involved creating the URL differently would end up working -- in the
end, those URLs would be terminated with a slash, or at least would
not end up looking like a known directory to Tomcat. Other web
containers may do the same thing.
So a potential fix for Stripes to work around the fact that Tomcat
devs consider this not a bug is to have the form tag pop a / at the
end of beanclass based URLs when the method is POST (?).
My workaround is to make my URL patterns not overlap with actual
folders
-- changing jobs to job in @UrlBinding(/job/{$event}/{fullName
Re: [Stripes-users] Clean URLs failing on form post
William,
I had a question, which i think is unrelated to your original problem:
Why are you using : @HandlesEvent() instead of renaming the
Resolution handler methods to the name you pass in param of
@HandlesEvent ?
ie:
public Resolution save() throws SchedulerException {
instead of:
@HandlesEvent(save)
public Resolution saveJob() throws SchedulerException {
Regards,
Sam
On Thu, Feb 3, 2011 at 11:21 AM, Rose William william.r...@petermac.org wrote:
Hi Nikolaos,
It probably is!
In my case, the only thing in my folder structure was JSPs, so moving
them to some other folder structure would fix the issue.
More generally, though, I thought that part of the magic of
DynamicMappingFilter was supposed to be that one could have one's action
beans appearing to share the same folders as their resources (e.g. CSS,
JS, images) and so it ought not matter that the JSPs were there too.
Let's say I rearranged my JSPs, but also added some extra graphics and
stylesheets:
/jobs
/images
/add-icon.png
/del-icon.png
/css
/edit.css
/WEB-INF
/jsp
/jobs
/edit.jsp
/list.jsp
I still have the same problem with Tomcat adding a / to
/contextPath/jobs, despite following best practice for placement of
JSPs.
Kind regards,
William Rose
Business Intelligence Team Leader
Information Management
+61 3 9656 5231 | Level 8, St Andrews Place, East Melbourne VIC 3002
-Original Message-
From: Nikolaos Giannopoulos [mailto:nikol...@brightminds.org]
Sent: Thursday, 3 February 2011 2:11 PM
To: Stripes Users List
Subject: Re: [Stripes-users] Clean URLs failing on form post
William,
Isn't it best practice to place ones JSPs rooted under /WEB-INF. This
ensures that your JSPs are never directly accessible from the outside
while still allowing your ActionBean's to forward to them.
If you followed this then Tomcat nor any other Web Container would
succeed in placing a slash and matching your JSP structure.
Or am I missing something...?
--Nikoloas
Rose William wrote:
Hi there,
I found the recent discussion on the mailing list about clean URLs
seemingly failing to find the right event handler when a form is
POSTed, and saw a variety of solutions to creating the URL oneself.
After trying to debug the same issue myself, I think the reason for
this behaviour is tied up in Tomcat bug 32424 (see
https://issues.apache.org/bugzilla/show_bug.cgi?id=32424).
My web app is set up with DynamicMappingFilter applied to /*.
I have a WEB directory structure like this:
/jobs
/edit.jsp
/list.jsp
I have an action bean annotated like this:
@UrlBinding(/jobs/{$event}/{fullName})
There is a list event, new event and save event:
//@DefaultHandler
@DontBind
@HandlesEvent(list)
public Resolution list() throws SchedulerException {
s_log.debug(in list());
return new ForwardResolution(/jobs/list.jsp);
}
@HandlesEvent(new)
@DontValidate
public Resolution newJob() throws SchedulerException {
s_log.debug(in newJob());
return new ForwardResolution(/jobs/edit.jsp);
}
@HandlesEvent(save)
public Resolution saveJob() throws SchedulerException {
return new RedirectResolution(JobAction.class,
edit).addParameter(fullName, this.jobDetail.getFullName());
}
In edit.jsp, I have a form like this:
stripes:form name=jobEdit id=jobEditForm
beanclass=myorg.action.JobAction
[form fields]
stripes:submit name=save value=Save /
/stripes:form
What happens is that when the page is rendered, I get HTML like:
form id=jobEditForm name=jobEdit
action=/contextPath/jobs
method=post
The important thing to note here is that /contextPath/jobs resolves to
a folder -- the one that contains edit.jsp and possibly other
resources.
Ostensibly, DynamicMappingFilter caters for such things because it
waits until the request 404's before handling it. And when a link is
constructed or a form submitted using GET, everything is just fine.
The problem is that Tomcat, as per the bug above, sees that
/contextPath/jobs is a folder early in the processing of the POSTed
form and issues a redirect to /contextPath/jobs/. This happens means
all the POST data is dropped and a GET request to /contextPath/jobs/
with no extra parameters is issued.
Hence, Stripes will complain with errors like No default handler
could be found for ActionBean, or just show the default handler for
that action bean (in my case, if I uncommented the @DefaultHandler
annotation, I would always see the job list).
I think that this is why fixes proposed in the recent thread that
involved creating the URL differently would end up working -- in the
end, those URLs would be terminated with a slash, or at least would
Re: [Stripes-users] Clean URLs failing on form post
Hi Sam,
Partly history -- I've used Stripes like that previously and hadn't looked into
the auto-mapping.
I had also wanted to be extra explicit to make sure that naming weirdness
wasn't why my events were not dispatched correctly.
And for the new event specifically, methods named new are not allowed, so
@HandlesEvent is needed. I suppose I should call it create.
Kind regards,
William Rose
Business Intelligence Team Leader
Information Management
+61 3 9656 5231 | Level 8, St Andrews Place, East Melbourne VIC 3002
-Original Message-
From: samuel baudouin [mailto:osenseij...@gmail.com]
Sent: Thursday, 3 February 2011 2:32 PM
To: Stripes Users List
Subject: Re: [Stripes-users] Clean URLs failing on form post
William,
I had a question, which i think is unrelated to your original problem:
Why are you using : @HandlesEvent() instead of renaming the Resolution
handler methods to the name you pass in param of @HandlesEvent ?
ie:
public Resolution save() throws SchedulerException {
instead of:
@HandlesEvent(save)
public Resolution saveJob() throws SchedulerException {
Regards,
Sam
On Thu, Feb 3, 2011 at 11:21 AM, Rose William william.r...@petermac.org wrote:
Hi Nikolaos,
It probably is!
In my case, the only thing in my folder structure was JSPs, so moving
them to some other folder structure would fix the issue.
More generally, though, I thought that part of the magic of
DynamicMappingFilter was supposed to be that one could have one's
action beans appearing to share the same folders as their resources
(e.g. CSS, JS, images) and so it ought not matter that the JSPs were there
too.
Let's say I rearranged my JSPs, but also added some extra graphics and
stylesheets:
/jobs
/images
/add-icon.png
/del-icon.png
/css
/edit.css
/WEB-INF
/jsp
/jobs
/edit.jsp
/list.jsp
I still have the same problem with Tomcat adding a / to
/contextPath/jobs, despite following best practice for placement of
JSPs.
Kind regards,
William Rose
Business Intelligence Team Leader
Information Management
+61 3 9656 5231 | Level 8, St Andrews Place, East Melbourne VIC
+3002
-Original Message-
From: Nikolaos Giannopoulos [mailto:nikol...@brightminds.org]
Sent: Thursday, 3 February 2011 2:11 PM
To: Stripes Users List
Subject: Re: [Stripes-users] Clean URLs failing on form post
William,
Isn't it best practice to place ones JSPs rooted under /WEB-INF. This
ensures that your JSPs are never directly accessible from the outside
while still allowing your ActionBean's to forward to them.
If you followed this then Tomcat nor any other Web Container would
succeed in placing a slash and matching your JSP structure.
Or am I missing something...?
--Nikoloas
Rose William wrote:
Hi there,
I found the recent discussion on the mailing list about clean URLs
seemingly failing to find the right event handler when a form is
POSTed, and saw a variety of solutions to creating the URL oneself.
After trying to debug the same issue myself, I think the reason for
this behaviour is tied up in Tomcat bug 32424 (see
https://issues.apache.org/bugzilla/show_bug.cgi?id=32424).
My web app is set up with DynamicMappingFilter applied to /*.
I have a WEB directory structure like this:
/jobs
/edit.jsp
/list.jsp
I have an action bean annotated like this:
@UrlBinding(/jobs/{$event}/{fullName})
There is a list event, new event and save event:
//@DefaultHandler
@DontBind
@HandlesEvent(list)
public Resolution list() throws SchedulerException {
s_log.debug(in list());
return new ForwardResolution(/jobs/list.jsp);
}
@HandlesEvent(new)
@DontValidate
public Resolution newJob() throws SchedulerException {
s_log.debug(in newJob());
return new ForwardResolution(/jobs/edit.jsp);
}
@HandlesEvent(save)
public Resolution saveJob() throws SchedulerException {
return new RedirectResolution(JobAction.class,
edit).addParameter(fullName, this.jobDetail.getFullName());
}
In edit.jsp, I have a form like this:
stripes:form name=jobEdit id=jobEditForm
beanclass=myorg.action.JobAction
[form fields]
stripes:submit name=save value=Save /
/stripes:form
What happens is that when the page is rendered, I get HTML like:
form id=jobEditForm name=jobEdit
action=/contextPath/jobs
method=post
The important thing to note here is that /contextPath/jobs resolves
to
a folder -- the one that contains edit.jsp and possibly other
resources.
Ostensibly, DynamicMappingFilter caters for such things because it
waits until the request 404's before handling it. And when a link is
constructed or a form submitted using GET, everything is just fine
