You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Mind Bridge <mi...@yahoo.com> on 2005/01/15 23:48:38 UTC
Making links use POST rather than GET requests (a.k.a. links with many parameters of unlimited size)
Hi,
Since we are the ILinkRenderer topic:
In the past we have often encountered problems with the length of the URLs.
If the URL is longer than a certain number of characters, the browser starts
behaving stangely or plainly stops working. A person sent a very helpful
message a while ago that gave different "critical" URL sizes for a variety
of browsers. The minimum was 256 characters for mobile phones, so any URL
longer than that should not really be considered "safe".
I have created a special ILinkRenderer implementation for the link
components (DirectLink, ExternalLink, ActionLink, etc) that dynamically
creates an invisible form with the requested parameters using JavaScript.
Clicking on the rendered link submits that form and as a result the
parameters are passed to the server using a POST request with a very short
URL. The parameters are placed in hidden fields in the form and are not a
part of the submitted URL. The renderer preserves the correctness of the
HTML, and there is no problem using it within a form and in other
circumstances.
In short, that code allows you to have a lot of large parameters in your
link. You simply do not have to worry about a funny behaviour on part of the
browser due to extra long URLs.
I have published the code on T-Deli (http://www.t-deli.com) together with
some other things that may be useful.
The use of the renderer is very simple -- just add the 'renderer' parameter
to your DirectLinks or ExternalLinks (or other link components) like this:
<a jwcid="@DirectLink"
renderer="ognl: @org.mb.tapestry.link.FormLinkRenderer@RENDERER"
...
The generated links will automatically start using POST rather than GET
requests and their parameters passed to the server will no longer be limited
in size as a result.
Note that while at the moment this functionality may be useful only in some
cases, it will become absolutely essential in Tapestry 3.1 where URLs will
often contain some persistent properties and other information that needs to
be stored on the client side.
Best regards,
-mb
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Making links use POST rather than GET requests (a.k.a. links
with many parameters of unlimited size)
Posted by Luis Neves <ln...@netcabo.pt>.
Mind Bridge wrote:
>>256 characters is a very low number
>
>
> This is an article describing the issue (sent by Ido Tamir):
>
> http://www.jetools.com/content/resources/whitepapers/HTTP_GET_Requests.pdf
> (please click on the PDF)
Thanks for the link.
>>I have some reservations about this method and I really hope that
>>collectively we can find another solution for the problem.
>>For starters, it would seriously annoy some of "my" users because
>>since they started using FireFox they can't live with out opening
>>pages in multiple tabs.
>
>
> I believe the issue has been described on the -dev list somewhat.
> In any case, you do not have to change anything -- storing some properties
> on the client side will only be done if you choose to do so. You will also
> be able select how long the information will live. In other words, if the
> application works now, it will work then as well -- no change is needed.
My mistake, sorry... you said that this change will be "absolutely
essential", I read that as non-optional.
Regards,
Luis Neves
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Making links use POST rather than GET requests (a.k.a. links with many parameters of unlimited size)
Posted by Mind Bridge <mi...@yahoo.com>.
> 256 characters is a very low number
This is an article describing the issue (sent by Ido Tamir):
http://www.jetools.com/content/resources/whitepapers/HTTP_GET_Requests.pdf
(please click on the PDF)
As you can see, the issue affects quite a number of browsers, not only those
on some mobile phones.
> I have some reservations about this method and I really hope that
> collectively we can find another solution for the problem.
> For starters, it would seriously annoy some of "my" users because
> since they started using FireFox they can't live with out opening
> pages in multiple tabs.
I believe the issue has been described on the -dev list somewhat.
In any case, you do not have to change anything -- storing some properties
on the client side will only be done if you choose to do so. You will also
be able select how long the information will live. In other words, if the
application works now, it will work then as well -- no change is needed.
This is just a possibility that will be quite useful in some cases and I
think it will be particularly helpful in some multiple window/multiple tab
situations (as they have an effect similar to the Back button and minor
client side storage is the only solution)
----- Original Message -----
From: "Luis Neves" <ln...@netcabo.pt>
To: <ta...@jakarta.apache.org>
Sent: Monday, January 17, 2005 2:11 PM
Subject: Re: Making links use POST rather than GET requests (a.k.a. links
with many parameters of unlimited size)
> Hi,
>
> Mind Bridge wrote:
> > Hi,
> >
> > Since we are the ILinkRenderer topic:
> >
> > In the past we have often encountered problems with the length of the
URLs.
> > If the URL is longer than a certain number of characters, the browser
starts
> > behaving stangely or plainly stops working. A person sent a very helpful
> > message a while ago that gave different "critical" URL sizes for a
variety
> > of browsers. The minimum was 256 characters for mobile phones, so any
URL
> > longer than that should not really be considered "safe".
>
> 256 characters is a very low number, are these "modern" mobile phones?
> Are you sure that devices with this low limit have the necessary
> Javascript functionality to make this work?
>
>
> > Note that while at the moment this functionality may be useful only in
some
> > cases, it will become absolutely essential in Tapestry 3.1 where URLs
will
> > often contain some persistent properties and other information that
needs to
> > be stored on the client side.
>
> I have some reservations about this method and I really hope that
> collectively we can find another solution for the problem.
> For starters, it would seriously annoy some of "my" users because
> since they started using FireFox they can't live with out opening
> pages in multiple tabs.
> This would also, I think, affect the 3.1 objective of "Friendly
> URLs", it would force me to redesign the caching strategies for some
> of my apps which rely on the fact that GET requests are idempotent, it
> would be conceptually similar to the ASP.NET approach of the
> "doPostBack" method which I know creates some problems (I will try
> speak with the resident .NET team to find out what exactly are the
> problems) and it would make "page refreshing" really annoying, unless
> we do a redirect after post.
>
> Best regards,
> Luis Neves
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Making links use POST rather than GET requests (a.k.a. links
with many parameters of unlimited size)
Posted by Luis Neves <ln...@netcabo.pt>.
Hi,
Mind Bridge wrote:
> Hi,
>
> Since we are the ILinkRenderer topic:
>
> In the past we have often encountered problems with the length of the URLs.
> If the URL is longer than a certain number of characters, the browser starts
> behaving stangely or plainly stops working. A person sent a very helpful
> message a while ago that gave different "critical" URL sizes for a variety
> of browsers. The minimum was 256 characters for mobile phones, so any URL
> longer than that should not really be considered "safe".
256 characters is a very low number, are these "modern" mobile phones?
Are you sure that devices with this low limit have the necessary
Javascript functionality to make this work?
> Note that while at the moment this functionality may be useful only in some
> cases, it will become absolutely essential in Tapestry 3.1 where URLs will
> often contain some persistent properties and other information that needs to
> be stored on the client side.
I have some reservations about this method and I really hope that
collectively we can find another solution for the problem.
For starters, it would seriously annoy some of "my" users because
since they started using FireFox they can't live with out opening
pages in multiple tabs.
This would also, I think, affect the 3.1 objective of "Friendly
URLs", it would force me to redesign the caching strategies for some
of my apps which rely on the fact that GET requests are idempotent, it
would be conceptually similar to the ASP.NET approach of the
"doPostBack" method which I know creates some problems (I will try
speak with the resident .NET team to find out what exactly are the
problems) and it would make "page refreshing" really annoying, unless
we do a redirect after post.
Best regards,
Luis Neves
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org