Joseph Smarr

Thoughts on web development, tech, and life.

Month: June 2007

Great video interview about lunch 2.0

The PodTech crew shot and edited a really nice video at our recent Lunch 2.0 at Netgear. It covers the event and features an interview with the lunch 2.0 founders, including your humble narrator, on the origins of Lunch 2.0.

I conducted the entire interview while lying on a bed in Netgear’s “lifestyle room” showcase, watching TV using their wireless media center product. And I’m wearing a commemorative Netgear apron from their BBQ lunch.

I love living in Silicon Valley. 🙂

Here’s the video (thanks, Jeremiah!):

Twitter status and upcoming events now on my blog sidebar

BTW, I’ve added my current twitter status (using Twit-Twoo) and events I’m attending (via to the left sidebar of my blog. It’s cool how easy it is these days to integrate data from third-party sites without having to write any API client code. Like we found with Plaxo’s widget, when you can just give people some HTML/JavaScript to copy and paste, the barrier to adoption is dramatically lowered compared to requiring even simple direct API consumption.

Of course, as someone who reads blogs exclusively inside Bloglines, I rarely see the actual web pages where people host their blogs. If you’re like me, now you know I have this extra info on my site. But from what I’ve seen, it appears many (if not most) people still read blogs by typing in the URLs and seeing if there’s anything new. It seems crazy not to take advantage of RSS, especially given how user-friendly many blog readers are these days, but I guess old habits die hard. 🙂

WordPress "XML-RPC server accepts POST requests only."

This morning I found I couldn’t publish to WordPress using Windows Live Writer any more. I would get errors like “Invalid Server Response – The response to the blogger.getUsersBlogs method received from the weblog server was invalid.” and when I looked at the request in HTTPAnalyzer, WordPress’s xmlrpc.php was sending “XML-RPC server accepts POST requests only.”, even though I WAS posting. Since WordPress’s WSYWIG and HTML editors both horribly mangle any code samples you try to use, this was quite frustrating.

But after a bit of Googling, I found a quick solution that worked perfectly. Just add the following line of PHP to the top of your xmlrpc.php file (inside the <?php of course):

$HTTP_RAW_POST_DATA = file_get_contents("php://input");

Thanks to helpful bloggers like Will for reporting solutions to problems like this, and thanks to Google for helping other distressed hackers find them! I hope this increases the ease with which this particular solution can be found by others.

The hidden cost of meta-refresh tags

We just discovered at Plaxo that redirecting using meta-refresh tags has a surprising performance penalty as a side-effect: it causes all cached resources on the redirected-to page to be re-requested (as if the user had hit the “refresh” button). Even though most of them should return 304s (if you’re caching them properly), this still results in a ton of extra requests and round-trips. A good workaround is to replace the meta-refresh tags with JavaScript redirects.

A bit more detail

A standard technique for redirecting users from one web page to another is to put a “meta refresh” tag in the first page that says to immediately redirect to the other page, e.g.

<meta http-equiv=refresh content="0; url=http://new-page" />

When browsers see this, they go to the URL specified, and if the time specified before redirecting is (the “0;” in the above example), they’re even smart enough to remove the redirecting page from the browser history so when you press Back you don’t get re-redirected.

However, there is a side effect that none of us knew about or expected. We only discovered it while performance-tuning Plaxo Online 3.0 (coming real soon now!!) while using HTTPAnalyzer. For some people, after the initial visit to the site, on return visits none of the images would be re-requested (we send long cache expiration times, so this is good behavior). But for others, they’d be requested each time they went to the page.

The difference turned out to be that some people were accessing the site by a slightly different URL that uses a meta-refresh tag to go to the actual site. Since “http-equiv=refresh” means “treat this as if I’d sent the equivalent HTTP header ‘refresh'”, the browser (especially IE) acts as if the user had hit the reload button and re-requests all cached images on the redirected-to page with If-Modified-Since and If-None-Match headers. If you’ve got the right cache headers, these requests will all return 304 (i.e. the images won’t actually be re-downloaded), but it still results in a big–and unnecessary/unintended–performance hit because you’re now sending a bunch of extra round-trip requests while loading the page.

The ideal solution for redirecting is to send a 302 redirect response from the web server itself to avoid even loading the intermediate web page. However, there are times when this isn’t feasible, e.g. if you don’t have that level of control over the server or if your template system wants to only do this if certain variables are set. Another case is if you want to redirect from an HTTPS page to an HTTP page–if you try to do this on the server, you’ll get a browser warning about redirecting from a secure page to an insecure page, but if you do it with meta-refresh, it works fine (bravo, browser security dudes, heh). So in these cases you want to redirect client-side, but you don’t want to incur the side-effect of re-fetching all the cached resources.

A good solution is to use JavaScript (while some web developers like to degrade gracefully when JavaScript is disabled, we’re redirecting to a rich Ajax app, so this isn’t really an issue). Wherever you’d use a meta-refresh tag, instead insert the following script block:

<script type="text/javascript">

By using location.replace (instead of, say, location.href=), the browser will purge the redirecting page from the browser history, just like a meta-refresh tag with 0 wait time, which is a good thing. And you won’t get any bad caching side effects, which is also a good thing.

Thanks to the two Ryans for figuring this out! Now you know too. 🙂

explanation of business lead articles explanation of newbusiness lead opportunities explanation of finance lead deposit explanation of moneymaking lead art explanation of loan lead deposits explanation of makeyour lead home good explanation of income lead issue explanation of medicine productivity

© 2017 Joseph Smarr

Theme by Anders NorenUp ↑