About the Author

Chris Shiflett

Hi, I'm Chris, a web developer and a founding member of Analog. I live and work in Brooklyn, NY.

Google Web Accelerator and PHP

You've probably heard about the new Google Web Accelerator, but if you're like me, you haven't bothered to try it out or give it much thought. After all, it can't possibly be worth running Windows. If you develop PHP applications, however, you might want to pay attention.

There is a particular section of the HTTP specification that is frequently violated. Section 9.1.1 of RFC 2616 states the following:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

What does this mean? If you use $_REQUEST, rely on register_globals, or deliberately use $_GET to process a request that performs some action (other than retrieval), then you're violating the HTTP specification, because a GET request can potentially perform that action. If your page contains links that perform an action (when followed), then the Google Web Accelerator is going to cause you problems. You can already find complaints about this. Of course, the developers complaining are the ones to blame, not Google.

The moral of the story is to adhere to the HTTP specification. If you want to play the web game, you have to play by the rules.

About This Post

Google Web Accelerator and PHP was posted on Tue, 24 May 2005 at 04:07:00 GMT.

18 Comments

1. AMiGo's GravatarAMiGo said:

Wait a minute... Standart says "SHOULD", not "MUST". Google is one to blame, because it MUST NOT rely on recommendations ("SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful" - RFC 2119)

Tue, 24 May 2005 at 06:38:23 GMT Link

2. Ren's GravatarRen said:

The Standard says "SHOULD" and not "MUST" because there are valid cases when you want GET todo something more than just retrieval. Tracking users as they travel around your site is one of them.

Tue, 24 May 2005 at 11:42:55 GMT Link

3. Ben Ramsey's GravatarBen Ramsey said:

Recommendations are just that: recommendations. However, if enough people agree to follow the recommendation, then it becomes the standard. If everyone agrees to follow the standard, then it makes the lives of all developers much easier. So, just follow the "standard" and don't argue with it.

Then, when everyone is following the standard, we can all hold hands around the camp fire and sing "Kum Bye Ya" late into the night. What a wonderful world it would be!

Tue, 24 May 2005 at 14:58:57 GMT Link

4. Joshua Eichorn's GravatarJoshua Eichorn said:

It doesn't matter what the recommendation in the standard is, people use get for things like delete links because there is no simple way to do it with post. Making every action link a form is a pain, besides the fact that there is no none javascript way that I know of, that can submit a form from a normal a link.

Tue, 24 May 2005 at 16:41:24 GMT Link

5. Padraic Brady's GravatarPadraic Brady said:

I have to agree that from a purely convenience perspective use of links to trigger an action just makes more sense then creating a form and button. It's simple, easy to do, and users are used to it (I assume).

Sure the world would be simpler if "recommendations" were followed, but in some cases convenience outweighs the scenic route of adding a form.

The point is that Google should have been aware that this recommendation was either a) not implemented in many applications (for whatever reason), or b) pretty obscure for most folk, so probably ignored.

Didn't they test this before going online? I know they had a good idea, but it's effects should have been easily forseen...

Tue, 24 May 2005 at 17:57:08 GMT Link

6. Ilia Alshanetsky's GravatarIlia Alshanetsky said:

There is an ocean of difference between a recommendation and a rule. The usage of POST for action events is merely a recommendation, which is not really practical in most situations. Enforcing recommendations as rule is a quick recipe to a disaster as this situation demonstrates. You’d think a company that has been parsing web pages for many years now and is surely aware of HTML’s “flexibility” would use more caution when implementing caching functionality.

Tue, 24 May 2005 at 22:06:18 GMT Link

7. Chris Shiflett's GravatarChris Shiflett said:

It's the difference between being unconditionally compliant and conditionally compliant. Imagine if web servers didn't send a Content-Type header:

"Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body."

I think the term conditionally compliant is pretty accurate, even if it is slightly less harsh than my description of such applications. :-)

Tue, 24 May 2005 at 22:19:51 GMT Link

8. Ren's GravatarRen said:

I dont understand what the real difficulty in using a form over a hyperlink is.

Wed, 25 May 2005 at 00:29:24 GMT Link

9. C Drozdowski's GravatarC Drozdowski said:

Maybe you "should" ;) write an article on how GWA could possibly effect web app security and post it on http://phpsec.org/. It's not much of a idea but...

At least there would be some fresh content on the site besides postings about upcoming conferences and references to Brain Bulb.

Wed, 25 May 2005 at 01:33:10 GMT Link

10. Ilia Alshanetsky's GravatarIlia Alshanetsky said:

Ren: consider an average forum page where there are probably close to 50 - 100 links depending on the nature of the page and the viewing user. About 10-20% of those links trigger various events, like "subscribe", "mark read" and so on. Can you see having 20-30 form buttons on there? Heck, in forums, clicking on an unread topic is an event, which marks that topic as read...

Chris: There is a difference between web server complaince and web page compliance. Surely you are aware that HTML standards are not closely followed for one reason or another. Expecting designers to adhere to recommendations set by W3C is like giving a kid a gun and expecting him not to injure someone or himself.

Wed, 25 May 2005 at 02:40:39 GMT Link

11. Chris Shiflett's GravatarChris Shiflett said:

Yes, I think I understand the reason for the situation. I'm just not being my usual sympathetic self. :-)

Most of the developers who are complaining should recognize that they share some (most?) of the responsibility. I would be willing to bet that most of them aren't deliberately choosing to ignore the "SHOULD NOT" wording of the specification. I bet they're not even aware of the specification. :-)

Wed, 25 May 2005 at 02:47:35 GMT Link

12. Al's GravatarAl said:

I admit I was not aware of the specification, and am appreciative to Chris for pointing it out. I do plan to adhere to this specification in the future, because honestly I don't see a big problem with using POST, instead of GET. I may not have the most complicated applications, but... You don't have to use form buttons to submit a form, you can make an image or link submit, with some basic JavaScript, something I am not fond of doing, but the alternative is not acceptable.

Wed, 25 May 2005 at 03:22:05 GMT Link

13. Chris Shiflett's GravatarChris Shiflett said:

There are several hundred interesting comments posted to the article I referenced:

http://www.37signals.com/svn/archiv...p_designers.php

Wed, 25 May 2005 at 03:29:26 GMT Link

14. Padraic Brady's GravatarPadraic Brady said:

Yep, I was definitely not aware of the recommendation either. Was anyone? ;)

Using GET is so widespread though that its just assumed as acceptable practice - over time those assumptions outweigh a recommendation most developers are not aware of - afterall if everyone else is doing it... Sure it's no doubt technically wrong, but in reality its done. Can anyone foresee a sudden shift in the short to medium term? I doubt it very much. Instead developers will fight back with 403's or 401's left and right as a more immediate (and therefore realistic) workaround.

As for responsibility - it sucks, but its developers fault to a degree but...

Google should deal in reality - not wishful thinking.

Wed, 25 May 2005 at 07:48:20 GMT Link

15. Ren's GravatarRen said:

Illia,

Whats wrong with 20-30 form buttons? They're no different to hyperlinks. You can use CSS to make them look like hyperlinks. Though I'm not sure thats a good idea, buttons and hyperlinks look different for a reason.

Clicking on a topic and marking as unread isn't that a destructive operation. Ok, have lost some usability, but this can be regained by not marking an item as read when the UA is GWA.

Wed, 25 May 2005 at 09:20:50 GMT Link

16. Christopher Baus's GravatarChristopher Baus said:

I am pushing the blame back to Google. Regardless of SHOULDs ands MUSTs, that's how the web works. Google is generally a pretty pragmatic company, but in this case their proxy doesn't work with existing apps, and that is bad.

I also agree with other commentors that say to be compliant you only have to comply with the MUSTs. The spec is pretty clear about that.

Wed, 25 May 2005 at 17:00:05 GMT Link

17. Ilia Alshanetsky's GravatarIlia Alshanetsky said:

Ren: Not all browsers fully support CSS, many corporate networks still use Netscape 4.7 as their prescribed browser of choise. From the browsers that do support CSS not all fully or identically handle the styles necessary to make buttons appear as links. Then consider the inflated size of your page thanks to all simple (GET) links being converted to forms with hidden fields and so on...

I'd think you'll soon find that conversion is not as practical as it may seem initially.

Thu, 26 May 2005 at 15:51:28 GMT Link

18. Kevin D. Kinsey's GravatarKevin D. Kinsey said:

Ilia has some good arguments ... server load and increased web traffic are two point I've not seen anyone else mention. See his blog at http://ilia.ws/archives/46-Google-Web-Accelerator-and-the-dangers-of-prefetching.html

Tue, 31 May 2005 at 18:49:37 GMT Link

Post A Comment

Personal Details and Comment

Style Guide

Line breaks are converted to paragraphs. Also use:

  • <a href="" title="">text</a>1
  • <em>text</em>
  • <blockquote><p>text</p></blockquote>
  • <code>2  <?php  if ($foo) {      $foo = TRUE;  }  ?></code>
  1. Note: <code> can be used inline (e.g. in paragraphs) or in a block as shown. Include whitespace and newlines in blocks.

Please enter Chris (my first name) below. This is a primitive spam prevention technique, and I apologize for the inconvenience.

Preview and Submit

Upcoming Talks

ConFoo

10 - 12 Mar 2010

At Hilton Montréal Bonaventure, Montréal, Canada.

South by Southwest

12 - 16 Mar 2010

At Austin Convention Center, Austin, Texas.

Dutch PHP Conference

10 - 12 Jun 2010

At TBD, Amsterdam, Netherlands.

O'Reilly Open Source Convention

19 - 23 Jul 2010

At Oregon Convention Center, Portland, Oregon.

New Comments

Niall Kelly wrote:

Having tried other methods without success and looked through plenty of bloated documentation, th...

Posted in Git on Snow Leopard
liukang wrote:

I have problem with this example. In my php.ini magic_quotes_gpc is off so i'm using only addsla...

Posted in addslashes() Versus mysql_real_escape_string()
RyanTheGreat wrote:

Well, I'm not Chris, but I will do my best to address the questions raised in the comments by Ian...

Posted in Security Corner: Cross-Site Request Forgeries
Chris Shiflett wrote:

Thanks for the kind words, Simon. I'm glad you liked the tutorial. In case it's helpful, here'...

Posted in Webstock
Chris Shiflett wrote:

Hi Robin, I plan to post something about it, but it's going to be hard to express everything i...

Posted in Webstock

Browse Comments

Work and Books

Analog Essential PHP Security HTTP Developer's Handbook