views:

80

answers:

5

Hello...

So, we have a very large and complex website that requires a lot of state information to be placed in the URL. Most of the time, this is just peachy and the app works well. However, there are (an increasing number of) instances where the URL length gets reaaaaallllly long. This causes huge problems in IE because of the URL length restriction.

I'm wondering, what strategies/methods have people used to reduce the length of their URLs? Specifically, I'd just need to reduce certain parameters in the URL, maybe not the entire thing.

In the past, we've pushed some of this state data into session... however this decreases addressability in our application (which is really important). So, any strategy which can maintain addressability would be favored.

Thanks!

Edit: To answer some questions and clarify a little, most of our parameters aren't an issue... however some of them are dynamically generated with the possibility of being very long. These parameters can contain anything legal in a URL (meaning they aren't just numbers or just letters, could be anything). Case sensitivity may or may not matter.

Also, ideally we could convert these to POST, however due to the immense architectural changes required for that, I don't think that is really possible.

+3  A: 

If you don't want to store that data in the session scope, you can:

  • Send the data as a POST parameter (in a hidden field), so data will be sent in the HTTP request body instead of the URL
  • Store the data in a database and pass a key (that gives you access to the corresponding database record) back and forth, which opens a lot of scalability and maybe security issues. I suppose this approach is similar to use the session scope.
Guido
+2  A: 

most of our parameters aren't an issue... however some of them are dynamically generated with the possibility of being very long

I don't see a way to get around this if you want to keep full state info in the URL without resorting to storing data in the session, or permanently on server side.

You might save a few bytes using some compression algorithm, but it will make the URLs unreadable, most algorithms are not very efficient on small strings, and compressing does not produce predictable results.

The only other ideas that come to mind are

  • Shortening parameter names (query => q, page=> p...) might save a few bytes

  • If the parameter order is very static, using mod_rewritten directory structures /url/param1/param2/param3 may save a few bytes because you don't need to use parameter names

  • Whatever data is repetitive and can be "shortened" back into numeric IDs or shorter identifiers (like place names of company branches, product names, ...) keep in an internal, global, permanent lookup table (London => 1, Paris => 2...)

Other than that, I think storing data on server side, identified by a random key as @Guido already suggests, is the only real way. The up side is that you have no size limit at all: An URL like

example.com/?key=A23H7230sJFC

can "contain" as much information on server side as you want.

The down side, of course, is that in order for these URLs to work reliably, you'll have to keep the data on your server indefinitely. It's like having your own little URL shortening service... Whether that is an attractive option, will depend on the overall situation.

I think that's pretty much it!

Pekka
I'm actually leaning towards the compression route... it looks like with gZip I can get some from 1400 characters down to 1000... I'll have to run some more tests though to make sure this is actually worth it. Your other suggestions are all very good also.
Polaris878
+1  A: 

One option which is good when they really are navigatable parameters is to work these parameters into the first section of the URL e.g.

http://example.site.com/ViewPerson.xx?PersonID=123 => http://example.site.com/View/Person/123/

David Waters
Yes, this is a really good suggestion... I wish we would've planned our site with this in mind. It would be much easier to avoid these problems. This might actually be possible given our specific situation. Thanks!
Polaris878
+1  A: 

If the data in the URL is automatically generated can't you just generate it again when needed?

With little information it is hard to think of a solution but I'd start by researching what RESTful architectures do in terms of using hypermedia (i.e. links) to keep state. REST in Practice (http://tinyurl.com/287r6wk) is a very good book on this very topic.

Phillip Calçado
+1  A: 

Not sure what application you are using. I have had the same problem and I use a couple of solutions (ASP.NET):

  1. Use Server.Transfer and HttpContext (PreviousPage in .Net 2+) to get access to a public property of the source page which holds the data.
  2. Use Server.Transfer along with a hidden field in the source page.
  3. Using compression on querystring.
Josh