I'm surprised you blame us for the way Jeff is perceived. The only thing I think we could have maybe done better is omit the links to his actual replies. In retrospect, that might have been better. Our link text is pretty benign, e.g., "Then, we heard from Jeff."
The story is simple. We offered to save the likes of users who asked us to. Jeff objected, so we didn't. We offered to save the recipe data and make a searchable index. Jeff objected, so we didn't. While we might have been surprised, we complied; we didn't want to ruffle any feathers.
I can only imagine that you either object to the fact that we started the Open Recipes project or that we shared the story behind it. Either way, I'm afraid I just don't care. If there are exactly two people who think we did something wrong here, and lots of people who support what we're doing, then I think we chose wisely.
Also, you can't truthfully claim that anything we're doing is competing with Punchfork. (It was shut down at the end of March, before the Open Recipes project existed.) Not that there's anything wrong with competition.
It's cool. Like I said, I'm sure you're not alone.
Also, you make a very good point. We never expected to have to pause, but we should have put more focus on making sure people never felt their data was trapped, even in the very beginning.
In fact, you've managed to convince me that proper data export should be the very next feature we add.
Mapalong is still in private beta, but it's otherwise alive and well. It's a huge bummer that you think otherwise. I'm sure you're not alone.
We have had to pause development, but not only is your data still there, you can still use it. New users can't join, but that's about it.
As soon as we're able, we want to finish it and launch it. As part of this, we'll make sure people can get their data out in useful formats. (Perhaps a GeoRSS feed per URL? A KML file per user?)
I genuinely respect you for holding us to a high standard, but I think it's a little unfair to criticize us for an unfinished app.
It's more complicated than that. The last line has to match two out of three (for example, city and ZIP), and then it can try to do some reverse analysis on what you've written for the address line. (Even that's an oversimplification; it's pretty darn impressive.)
The USPS also has the additional challenge of matching what you think is your address with what is actually your address. Very, very few people know their address.
If that's not bad enough, if you've ever had something arrive successfully, you expect the address that was used to work forever.
IE is not preferring anything in your example. The default quality is 1.0, and since no quality is indicated for any type, they all share the highest preference.
Although IE's Accept header is technically useless, it's more likely to be a response to developers incorrectly parsing Accept than the other way around. This post is about sites using primitive string matching to parse Accept, and it's not unreasonable to imagine that this problem is not new.
You also claim that the spec leaves the resolution between text/html and text/* ambiguous, but it clearly states why text/html has precedence:
"If more than one media range applies to a given type, the most specific reference has precedence."
Lastly, I only get in a huff when people use illogic, especially ad hominems, to prop up a poor argument. In fact, I've written about this, too:
Safer? The risk is that 303 is misinterpreted, and this risk is why we have always used 302. I'd need evidence before taking a chance based on someone's recollection of an older version of Firefox.
RFC 2616 mentions early misinterpretations; they are why 303 and 307 exist:
"Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client."
Recommending 303 sounds like a great idea, but the spec's description of 303 is what 302 is in practice, and the latest spec (2616) makes note of this reality. Also, consistent support for 303 is not a sure bet:
"Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303."
Without evidence, using 303 is the riskier option.
This post seems to be based on the belief that everything adheres to the spec. Historically, 302 has always been interpreted like 303 is defined, and never like 302 is defined. For example:
"If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued."
Does the browser you use do that?
As with cookies, developers go with what works, even if it isn't exactly what the spec says.
History aside, it could be that there is now a difference in how 302 and 303 are interpreted by modern browsers, and I would love to see definitive tests. Any volunteers?