Serialize post and store it for later

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
shiznatix
DevNet Master
Posts: 2745
Joined: Tue Dec 28, 2004 5:57 pm
Location: Tallinn, Estonia
Contact:

Serialize post and store it for later

Post 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 ;)
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post by RobertGonzalez »

Have you tried to break it yet, just to see if there are issues with it?
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post 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.
User avatar
shiznatix
DevNet Master
Posts: 2745
Joined: Tue Dec 28, 2004 5:57 pm
Location: Tallinn, Estonia
Contact:

Post 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.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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.)
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post 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.
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post 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().
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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)
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post 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.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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..
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post 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.
User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

Post by Luke »

::steers people back to original question::
User avatar
shiznatix
DevNet Master
Posts: 2745
Joined: Tue Dec 28, 2004 5:57 pm
Location: Tallinn, Estonia
Contact:

Post 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
User avatar
julian_lp
Forum Contributor
Posts: 121
Joined: Sun Jul 09, 2006 1:00 am
Location: la plata - argentina

Post 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 :(
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Post by Benjamin »

FYI: Google will not index any pages containing a variable named "id" in the url.
Post Reply