Scripting News for 8/21/2006

PodCamp in Boston, September 9-10. 

Rising Tide/New Orleans, August 25-27. 

New header graphic, a hiking trail in Shenandoah National Park in Virginia. 

Niall Kennedy: “SF Tech Sessions meets this Wednesday evening in San Francisco to learn about the latest trends in distributing large media files.” 

The Onion: “Wikipedia, the online, reader-edited encyclopedia, honored the 750th anniversary of American independence on July 25 with a special featured section on its main page Tuesday.” 

Mitch Kapor: “Second Life is a disruptive technology on the level of the personal computer or the Internet.” 

Learned the hard way… I like to use redirects as part of the user interface for my web apps. Rather than display an error message saying you have to configure the app, I just redirect to the configuration page. My framework only allows one kind of redirect, so I always do a permanent one, HTTP result code 301. Everything worked fine, but something apparently changed in Firefox and now it notes 301s, and implements them on the client side. It probably seems like an economy of some sort, but it broke a few of my apps, and it took the longest time to figure out why. Not saying they did anything wrong, but making a note so that next time maybe I’ll remember it, and save some time. Or maybe this will save you some time. Back to work. 🙂 

A more careful explanation of the redirect issue. 

David Hornik’s view of the Friday TechCrunch party.  

One thing to be thankful for is that in all the reviews of Friday’s party, very few said it was about Web 2.0. We seem to have gotten that out of the way. Arrington’s parties are inclusive, and net-net that’s a good thing. Web 2.0, as designed by O’Reilly and Battelle, excludes lots of good people, and that’s a bad thing. I’d argue it’s even bad for O’Reilly and Battelle, but I’m not so worried for them.  

New mobile stuff 

Try reading the mobile versions of these popular weblogs on your BlackBerry, Treo, or web-enabled cell phone.

GigaOm.

MicroPersuasion.

PaidContent.

ReadWriteWeb.

Scoble.

TechCrunch.

Not bad, eh? We’re getting somewhere, it seems. 🙂

24 responses to this post.

  1. Dave,

    Big fan so don’t take this as a flame but don’t you think re purposing the content of another blog under your domain without retaining the copyright info is wrong? In the same way as the podshow/rss debacle was wrong…

    Mike

    Reply

  2. Good point, I should put in the copyright info, if it’s present in the feed.

    One thing in my favor, Mike, is that I gave each of them ample time to object, I’ve been keeping them in the loop every step of the way. That’s soemthing Podshow didn’t do.

    Reply

  3. Mike, first the good news, then the bad.

    Good: I changed my app so that if the RSS feed has a copyright element, I show it at the bottom of the page.

    Bad: Only Readwriteweb and Scripting News have copyright elements. I’ve sent emails to Om, Mike, Robert, Richard and Staci giving them a heads up.

    Reply

  4. Dave, I’m been putting together a mobile web directory in OPML. I’ve put these blogs in there. I’m trying to get it to render at mobile.bbcity.co.uk using Map-A-Domain, but I’m getting an error – take a look. I’m not sure what the problem is, but it may have something to do with ownerEmail.

    Also, are you going to PodCamp?

    Reply

  5. Tom, what’s the url of the OPML file.

    Reply

  6. Have you seen the mobile version of bloglines.com from my previous comment ? You can use also skweezer ( http://www.skweezer.net/ or example : http://www.skweezer.net/skweeze.aspx?q=http%3A%2F%2Fscripting.com&i=1 ) it can useful for website without mobile version and/or heavy layout. I subscribed to the NYT Magazine RSS feed but the link of articles send to the full website. So I click on print link or use skweezer.

    Reply

  7. Speaking of OPML directories, There are now upwards of 2500 job feeds at:

    http://freecruiter.org/directory/

    Reply

  8. Posted by Ezra on August 21, 2006 at 1:33 pm

    As a web developer, I’m curious what you mean by implementing 301s on the client side– I mean, a browser is sort of by definition handling a 301 on the client side, right? Is there some kind of weird caching going on or something?

    Reply

  9. Ezra, it remembers the redirect.

    Suppose when you go to X

    I redirect you to Y.

    Next time you go to X, the browser doesn’t even talk to X, it just takes you to Y. (After all, it was a permanent redirect.)

    See how this breaks my app? The condition that made the redirect the right thing to do may no longer be true, but my app never gets a chance to not redirect.

    Reply

  10. Re: your comments on the media ignoring the war in favor of coverage of the Ramsey murder.

    See: http://blogs.timesunion.com/derosier/?p=86

    (form Reddit)

    Reply

  11. Posted by Ezra on August 21, 2006 at 4:06 pm

    Thanks, that does make sense, and I’ll make a mental note to watch out for it. Most of the time I use 302s. People used them interchangeably for so long, I do have to imagine a lot of stuff will break.

    I see why it might not technically be within a client’s prerogative not to check back with the server after a “permanent” redirect, but, geez, what a nickel and dimey way to get a couple of milliseconds of performance.

    Reply

  12. Ezra –

    I don’t think Firefox is trying for a performance improvement, they’re trying to be consistent with the intent of the 301 response. If a website operator says “301: this URL is not at this location anymore, now it is here”, they *want* the client to remember not to come back. For example imagine a weak site which suddenly becomes popular. The operator might setup a stronger site and redirect everyone to it. If everyone kept coming back to the wimpy site to redirect, it would defeat the purpose. I think that’s the difference between 301 and 302, you’re supposed to remember a 301 but a 302 is temporary.

    Ole

    Reply

  13. Dave,

    According to the HTTP 1.1 spec, 301 redirects are cacheable. From what I’ve read, it is considered ill-behaved for HTTP clients to NOT cache a 301.

    Ezra,

    I don’t think it’s an attempt to get performance on the client side. I think the 301 is intended to be a tool for webmasters to say “Quit coming to this location. Go here instead”.

    http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

    Reply

  14. Posted by Ezra on August 21, 2006 at 6:42 pm

    Yeah, I agree that this is in line with the spec. And part of me is happy that there seems to be a lot of “hey, maybe we should actually read this HTTP spec thingy” going around, because HTTP is really simple and elegant and useful. And I think that the Mozilla/Firefox project deserves some credit for raising the bar for standards compliance; 5-7 years ago, it used to be that you almost *had* to be sloppy if you wanted to build something that actually worked. Problem is, I’m still using a lot of stuff that was written back then; I suspect I’m not the only one…

    Reply

  15. Dave,

    I very much appreciate the work you’ve done to provide mobile versions of these sites. That being said, have you seen http://www.xfruits.com/? Looks like they do something similar. Have a look as it looks pretty interesting and provides other RSS services as well.

    Reply

  16. 10.3.2 301 Moved Permanently

    The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs.

    Reply

  17. PS.

    10.3.3 302 Found

    The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests.

    Reply

  18. I am parsing the rss feed of my technorati favorites into my blog.
    Here it is: http://blogrolle.net/feedreader/
    It is very simple and a river of news. Works fine on my blackberry.

    Reply

  19. […] I got burned again by the Firefox bug/feature where it implements permanent redirects without looping the server in, and this was really elaborately fcuked up. Okay, so I had a bug in some software and it was redirecting where it shouldn’t, and because I was doing permanent redirects, once I fixed the bug there was nothing I could do to Firefox to tell it to forget about my mistake (or was there? is there some programmer’s switch I can flip that tells it to forget about all the redirects it’s remembering? that would solve the problem). Anyway, so I map a different domain to the app, as I did last month when I hit this wall, and I used that one instead. However, I forgot to change the domain for the cookie the app was returning. So I spent hours chasing down a bug in some ancient mainResponder code that I haven’t looked at in this milennium, and therefore didn’t trust, when the problem was somewhere very far away, in my work around for this new weird and programmer-unfriendly behavior of Firefox’s. Now I know some idiot is saying it’s my fault for having bugs, but that’s ridiculous. If I have to write bug-free code to use Firefox as a development tool, well then I’d better find another browser. Unless there’s some hidden nerd switch (see above).  […]

    Reply

  20. Dave, if the problem is with just your browser, try flushing the Firefox cache. If the problem is with user’s browsers, try using 301 to permanently redirect back from the ‘wrong’ domain back to the ‘right’ domain. I haven’t tried this though so this trick *might* confuse the firefox into a tailspin. LOL.

    Reply

  21. Posted by Owyn on September 13, 2006 at 5:50 am

    “Dave, if the problem is with just your browser, try flushing the Firefox cache.”

    This should work as the re-directs are stored with Global History.

    See: http://wiki.mozilla.org/Browser_History:Redirects

    Reply

  22. Has clearing your cache helped? (Tools > Clear Private Data)
    Surely a desktop browser doesn’t store and remember everything, forever?

    Also, what results do you get in IE? (if you have access to try that)

    Reply

  23. […] I know the issue Dave had was discussed in the comments on his earlier post, but still; 301 (Moved Permanently) has been essentially unchanged in the HTTP/1.1 specification since 1997: “Clients with link editing capabilities SHOULD automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cachable unless indicated otherwise.” […]

    Reply

Leave a comment