Page 1 of 3

Serialize post and store it for later

Posted: Tue Aug 01, 2006 7:40 am
by shiznatix
Ok I have a search feature on this website I am making. I wanted 2 things with it.

1) pagentation
2) when you hit refresh or your back button it does not say you have to resubmit your post data

What I did is this:

Code: Select all

if (0 === count($_POST))
{
            $_POST = unserialize(base64_decode($_SESSION['_POST']));
}
else
{
            $_SESSION['_POST'] = base64_encode(serialize($_POST));
            $this->Redirect('Search', array('Action' => 'Search'));
}

//build everything off of the $_POST now to make your query

//after executing your query, do this:
$_SESSION['_POST'] = base64_encode(serialize($_POST));
now this works amazingly well because the method with this code in it is called before a bunch of other methods that use the $_POST stuff to make proper HTML and whatnot so I can use the links for the pagentation and everywhere the $_POST will be available but without it asking you to re-submit the form.

Question is though, is this a bad idea? Anyone see anything bad that could happen? all the $_POST stuff is cleaned and whatnot of course so thats not a problem. It seams to easy, but it gives me a bad feeling for some reason, like i am missing something here. Maybe some more eyes can let me know if they see a problem with this idea or let me know that it is a good idea ;)

Posted: Tue Aug 01, 2006 8:49 am
by RobertGonzalez
Have you tried to break it yet, just to see if there are issues with it?

Posted: Tue Aug 01, 2006 8:53 am
by Ollie Saunders
Ok I have a search feature on this website I am making.
2) when you hit refresh or your back button it does not say you have to resubmit your post data
Use GET?

Also in your code I don't get why you are base64_encoding $_POST.
And also (empty($_POST)) is more readible and faster than (0 === count($_POST))
Question is though, is this a bad idea? Anyone see anything bad that could happen?
Well $_POST can be up to 8meg big, so storing it in a session could add an overhead. Also browsers prompt you as to whether to resubmit POST for a reason, generally this is because POST data makes a change to a database. Again I'm wondering why you didn't use GET.

Posted: Tue Aug 01, 2006 9:14 am
by shiznatix
Everah wrote:Have you tried to break it yet, just to see if there are issues with it?
a little but I havn't had much time to take every possible angle at it.

Posted: Tue Aug 01, 2006 9:38 am
by Jenk
ole wrote:
Ok I have a search feature on this website I am making.
2) when you hit refresh or your back button it does not say you have to resubmit your post data
Use GET?

Also in your code I don't get why you are base64_encoding $_POST.
And also (empty($_POST)) is more readible and faster than (0 === count($_POST))
Question is though, is this a bad idea? Anyone see anything bad that could happen?
Well $_POST can be up to 8meg big, so storing it in a session could add an overhead. Also browsers prompt you as to whether to resubmit POST for a reason, generally this is because POST data makes a change to a database. Again I'm wondering why you didn't use GET.
SE spiders don't like (and often don't use) messy GET uri's properly.

POST is tidier and less restrictive. (GET is limited in length, total URI cannot be longer than 255 chars on 90%+ of browsers, POST is not limited with such a small amount.)

Posted: Tue Aug 01, 2006 9:41 am
by Ollie Saunders
POST is tidier and less restrictive. (GET is limited in length, total URI cannot be longer than 255 chars on 90%+ of browsers, POST is not limited with such a small amount.)
Try 4096 characters.
SE spiders don't like (and often don't use) messy GET uri's properly.
I'd be interested to see evidence of that.

Posted: Tue Aug 01, 2006 9:44 am
by RobertGonzalez
Ole got it, 4096.

As for the refresh, unless you are using a splash page, you are always going to get prompted for the 'Resend Post Data'. Back button preventing refresh can be handle with the cache-control settings in header().

Posted: Tue Aug 01, 2006 9:57 am
by Jenk
4096 is still a lot less than POST can handle, and if someone is entering a paragraph of text in an input or textarea, that is going to be one messy URI.

As for SEO; google for "SEO mod_rewrite" and you'll see countless pages related to improving your SEO optimisation with mod_rewrite (because it removes ?var=foo&var2=boo)

Posted: Tue Aug 01, 2006 10:20 am
by Ollie Saunders
4096 is still a lot less than POST can handle, and if someone is entering a paragraph of text in an input or textarea, that is going to be one messy URI.
Well then you would use POST.

You don't really seem to get it Jenk. GET is for getting stuff, requests, like searches.
And POST is for putting stuff like paragraphs of text or more.

What I would suggest if you wanted to use tidy URLs for searches is to use slashes:

Code: Select all

http://www.yoursite.com/search.php/query/fish/language/english/startrow/0/endrow/20
This can easily be achieved with a JavaScript submission. And because these will appear in $_SERVER['PHP_SELF'] they can easily be decoded server-side. What is more they stick, browsers and SEs will treat it as a separate page rather than a variant of search.php. Only downside is that this also means that if you have any external assets (imgs, css, js) you have to use a leading / in there hrefs and make them relative to the whole site rather than the current page.

This is what I do with all my projects since i've started using the Zend Framework.

Posted: Tue Aug 01, 2006 10:53 am
by Jenk
I get it just fine, but thanks for condescending all the same. :)

shiznatix is trying to avoid the resubmit post data dialog box for his users. His chosen method is to store $_POST in session and refresh/redirect without any post data, then restore $_POST from $_SESSION (or access the data within $_SESSION directly) on the new page.

Even though he has specified a search facility is the main problem area, this point is actually irrelevant, as no doubt the same problem is evident elsewhere... happens all the time, it's why nearly all forums now either use AJAX for new posts/threads, or redirect inbetween submission and viewing the new post/thread.

GET and POST are almost synonymous in functional results, they are simply medium for passing variables from client to server over HTTP, you could call them apples and oranges for all the names are worth as descriptions.

Some SE spiders do not make proper use of query strings, when I say that I don't mean they store each resulting output as a variant of the original, I mean some don't even use them when following links (they strip the querystring from the uri). This is a moot point for this topic because POST method also has the same problem, because the spiders don't often use POST at all.


So anywho.. before I get myself yet another warning, moving on..

Posted: Tue Aug 01, 2006 11:27 am
by Ollie Saunders
I get it just fine, but thanks for condescending all the same.
I'm sorry for that. Don't want to start a flame war here.
GET and POST are almost synonymous in functional results, they are simply medium for passing variables from client to server over HTTP, you could call them apples and oranges for all the names are worth as descriptions.
I don't agree with that. They are for two different types of action and should be used so.
I mean some don't even use them when following links (they strip the querystring from the uri).
Only the stupid ones IMO. If they do they are limiting there ability to access resources. I've seen sites that use URLs like this:

Code: Select all

www.site.com/index.php?page=home
www.site.com/index.php?page=contact
And although that is not something I would do myself I don't think a SE should punnish those that do and increasingly, they don't.
This is a moot point for this topic because POST method also has the same problem, because the spiders don't often use POST at all.
What kind of a search engine would trawl using POST?! That would be ridicous.
Even though he has specified a search facility is the main problem area, this point is actually irrelevant, as no doubt the same problem is evident elsewhere... happens all the time
Well this is my point I don't see browser's "do you want to submit?" prompt as a problem at all for POST data. Because POST data often adds, removes or updates records on a database and these sometimes involve money you don't want the same action to be performed twice by accident.

Posted: Tue Aug 01, 2006 11:30 am
by Luke
::steers people back to original question::

Posted: Wed Aug 02, 2006 1:59 am
by shiznatix
no no this is good stuff.

the reason i don't want to use GET is because I never want to turn anyone away from my website for any reason, thats stupid to do. Thats why I have to make sure that all the data can be submitted to the server and if its too long (which it probably would be if I used GET) then thats a client gone.

I will never force javascript on a user either, I don't browse with javascript and I think its poor web design to be forced to use javascript. Many websites do this and the only reason it seams is because they want to serve me ads and track what I do, screw that.

also, a stupid script kiddy can easily edit the url when stuff was submitted though GET and although I make sure everything is clean, I would like to just keep them from even trying and forceing my site to use more bandwidth to handle all their garbage.

Thats why I am going with POST. my design works oh so well because I can use links for pagentation and keep the search option select boxes with the right stuff selected.

On the other side, using GET would allow people to link someone else to the search. Like if I said 'check out the results on page 2 for this search: __link__' that would be good. I could do that if I used GET but not POST. I never ever want to turn someone away from my site if their browser does not support a long GET though.

So, continue your discussion, it certinaly helps.

edit: heres a link to the first search page (no where near done) but you can test it http://shiznatix.dreamhosters.com/nfw/Search.php

Posted: Wed Aug 02, 2006 2:29 am
by julian_lp
ole wrote:
SE spiders don't like (and often don't use) messy GET uri's properly.
I'd be interested to see evidence of that.
So you're saying/you think that search engines would index messy urls as well as simpler ones?
I'm interested beacause I've an app which uses messy urls *a lot*. Sadly, I wrote it knowing near nothing about what kind of url's search engines prefer :(

Posted: Wed Aug 02, 2006 2:38 am
by Benjamin
FYI: Google will not index any pages containing a variable named "id" in the url.