views:

952

answers:

2

I want to workaround the "Webpage has expired" issue. First, I just changed a POST to a GET, but that resulted in an error that my HTTP request exceeded the maximum size for a GET.

So, now I'm thinking to try the technique described in the link below (post, 303, redirect), but will I still have the same size limitation problem?

http://stackoverflow.com/questions/420103/what-is-the-correct-response-to-an-http-post-request

I seem to be in a pick-your-poison situation.

EDIT More detail:

What I'm "POSTING" are search criteria. The server responds with the results of the search. There are a lot of controls on the form, http://ifdefined.com/btnet/search.aspx, more if the user has added custom fields, and ASP.NET's "Viewstate" adds more bytes.

+1  A: 

When using the HTTP 303 response, you would normally redirect to a URL that does not contain the posted information. So you wouldn't run into the same URL size limitation problem. For example, an example might be the following:

    Client: GET /list
    Server: 200 OK
    [user clicks Delete button on item 5]
    Client: POST /delete?id=5
    Server: 303 See other (Location: /list)
    Client: GET /list
    Server: 200 OK

The browser would not show the result of the POST, but would immediately redirect to the URL listed in the Location: header.

Greg Hewgill
Greg - thanks. I edited the question to add more detail. I'm not sure, and I may be misunderstanding, but I don't think your answer fits my situation. I don't see how your answer allows me to avoid BOTH poisons.
Corey Trager
Semantically, the correct HTTP request type for a search would be a GET. You're not adding or changing any information on the site, so POST is not the right thing to do. You've chosen to use POST because of a limitation in the size of a URL, not for semantic reasons. I would suggest that if your URL is too long for a GET, that you simply have too many fields on the search form (dozens? hundreds?). I would consider rethinking your application design to reduce the number of fields, so that you can continue to use GET requests.
Greg Hewgill
(I knew you were going to say that...) I truly appreciate you taking the time to help. I'm not ungrateful. But here's what I'm thinking: My users are not telling me that I "have too many fields on the search form". The users like the design. I don't want to throw out what they like. Also, my users don't care about the "Semantically, the correct..." part either, and they shouldn't have to care. They just care about how the page looks and behaves. I want to overcome the purely technical obstacles and deliver the behavior they want. Changing behavior would be defeat.
Corey Trager
+1  A: 
  1. Store POSTed data on the server
  2. Redirect to /page?id=unique-id-of-the-data

Basically store them in a session. But if you use your own storage mechanism and generate new ID for every POST, it will work nicely with multiple windows open (windows share cookies, thus sessions).

porneL