Seems fine here. Check your browser settings (esp. obviously cache settings).

I expect test posts in this thread, no problem on that. I'll clean them up periodically, just put the word "test" in there.

To be clear, this problem is EXCLUSIVELY in Firefox. I have NEVER seen it in IE.

This seems to be missing from the response to firefox:

Cache-Control: no-cache

Strange that it sends this header to IE but not to Firefox?

Might be an idea to investigate further upon?

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9

no-cache
If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.

Just my 2 cents ;)

I'd also expect it to be some caching, though examining the headers for the comments page request shows that the server doesn't send anything related to cache (meaning the UA should always check to see if there's changes on the page with an If-Modified-Since header.)

Where is the Pragma:no-cache when I *first* go to the page (http://www.codinghorror.com/blog/archives/000422.html)?

These are the headers I just got...

Content-Length: 13176
Date: Wed, 19 Sep 2007 21:49:16 GMT
Content-Type: text/html
Content-Encoding: gzip
Etag: "0cb49f12fbc71:2e1"
Server: Microsoft-IIS/6.0
Last-Modified: Wed, 19 Sep 2007 21:20:46 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding

200 OK

So it looks like you are redirecting to a previously cached page. Am I missing something?

--Zumbas

Yes I agree with David, the server isnt sending no-cache to Firefox. (although I it does refresh for me when posted above test)

You could change the url slightly of the new page, so instead of "http://www.codinghorror.com/blog/archives/000955.html" it would look something like "http://www.codinghorror.com/blog/archives/000955.html#". That points to the exact same place, but should force firefox to refresh properly.

I'm not a web expert, but I'd say that "Cache-Control: no-cache" on /blog/archives/*.html just isn't enough. I usually do
Cache-Control: no-store, no-cache, must-revalidate
and it never failed on me.

Looks like you've killed your web server with people posting 'test' comments-- at least my attempt to post has timed out twice.

Anyway, you could try changing the url of the new page slightly, so instead of "http://www.codinghorror.com/blog/archives/000955.html" it would look something like "http://www.codinghorror.com/blog/archives/000955.html#". That points to the exact same place, but should force firefox to refresh properly.

I'm not claiming proficiency in JavaScript, but maybe you can hook a JS snippet to the Post-button to force a reload on Firefox (or non-IE browsers, if it happens with other browsers).

Has the downside of using JS, but it could be a servicable work-around.

Have you tried using a 303 instead of a 302? This clip from the RFC seems relevant:

" If the 302 status code is received in response to a request using
the POST method, 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."

I'm pretty sure that David is correct... usually it's something like this:

Cache-Control: no-cache
Pragma: no-cache
Expires: -1

Typically it's best to send all of them. There are also some extra arguments for cache-control, but I'm not sure what they are.

Might have to check on the caching behavior in apache or whatever server you are using. I vaguely remember some issue with etags...

I don't know if it will work but can't you try to put the meta tag (meta http-equiv="Cache-Control" content="no-store") - not "no-cache" - to prevent caching in Firefox?

According to the HTTP specs, Firefox is right (sometimes), IE is wrong.

According to the HTTP 1.0 spec (RFC 1945), a browser receiving a 302 in response to a POST request must not redirect without checking with the user first, and if the user approves, send a new POST, not a GET. In other words, a 302 in response to a POST is intended to be interpreted as "post not accepted, you might try posting over here instead", not as "post accepted, see here for result", which is how both IE and your server are obviously using it. The spec mentions that many browsers make this mistake.

The HTTP 1.1 spec (RFC 2616) repeats the note and seems to have given up on trying to persuade browser authors to get it right, because it adds, "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." 303 See Other is intended for returning the response to a POST, while 307 Temporary Redirect is intended for the post-here-instead situation.

Bottom line: It looks like you should be returning 303 instead of 302. (Possibly after checking that the browser speaks HTTP 1.1, but I doubt whether that would be an issue these days.)

(Disclaimer: I haven't tested any of this.)

Well, I'm not getting any issues. Great blog, BTW.

It is obviously "cache" day on the internet. An hour before reading this (btw - detetective work like this is one of my favorite things to do), I read about some problems Bret was having with retreiving files from the local cache (http://www.io.com/~wazmo/blog/archives/2007_09.html#000259).

Back to the detective work...

I have to point out (as well you know) that trying to fix this problem with Javascript or appending a # to the URL is completely avoiding the problem and definitely shouldn't be considered a solution.

Damn, I've had this exact problem and solved it too. But I can't remember what I did to fix it.

I think it was something to do with an ambiguous clause in some web standards somewhere.

It may be the forum should be sending a 303 (See Other) response too - that's the standard way to do a redirect after a post.

I'll dig around and see if I can remember what the problem was.

Gareth, I agree.

Also, I apologize for the comment timeouts. The comment system (movable type, perl, running on Win 2k3 server) is not the world's most robust, either..

> This seems to be missing from the response to firefox:

David, you've misread the data. It is in the form of:

POST Request (from BROWSER)
302 Response (from SERVER)
GET Request (from BROWSER)

The section you're referring to is sent by the browser as headers to the request, it is not a response from the server. Only that bit in the middle is from the server, and it is identical in both cases (and it contains pragma:no-cache too).

Worked fine for me.

Info: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

The Pragma: header appears to be ignored by most browsers.

I've found the following to work in my web applications:
Cache-Control: must-revalidate, no-cache

Works on my machine. Ta Ta.

Jeff,

I've never had that problem in firefox, however, as everyone else has already said, you need to use 303 to redirect, as 302 needs an acknowledgment or sorts from the end user...

I also noticed you're not using cookies for your sessions mgmt in Mozilla... I wonder if that would have anything to do with it....

A few years ago I managed a Mac open source site. This gave me some fun times.

One day a guy posted a full 100+ page functional spec for an application. The first page had the company name and "This is for internal usage only!" I quickly stopped reading at that point. The hilarious thing was the guy's comment: "I would appreciate if you could write this application by the end of the week. I can't pay you but you will have my gratitude." I didn't even bother responsing.

Another day and another guy saw me with another email: "I have this great idea for a piece of software. How much would you bid for it?" No hint of what the idea was. Just that: a bid on the unknown. For a laugh I responded, pointing out that I had so many ideas of my own that I didn't have anywhere near enough time to implement them all yet alone need other people's ideas. The fool then sent several hundred MiB of g@y porn. This shutdown my mail server. My ISP latter told me that the email source of all the porn was the same as the idea guy and that they had filed a complaint against that guy to his ISP. The ease that the source of porn was tracked down clearly showed what a great ideas man he was.

But the most lazy award is yet to be given. My web site was named after a brain cell. Anyone who visited it would see straight away that my site was about Mac software. One day I got an email from a guy: "Hi. I just visited your site and was wondering if you have an information about brain science that I can use in a uni project?"

There are some funny people out there. Every day my mailbox always had something from someone with the energy to write an email but not the strength to read more than one word.

This is too funny. I just submitted a post and got a flag for questionable content.

"porn" was accepted.

"g@y" was rejected.

A lot of happy people who dislike filth are going to feel discriminated against.

No problems here (Using FF). The problem must be in some server in the middle.

What double comments are you talking about?

"people who think their comments have been "lost""

This has happened to me in firefox while posting on youtube. NO idea if its something firefox-related.

Hi Jeff,

I haven't seen anybody mention this these two things and forgive me if they have.

I did notice one thing about your HTTP Requests that were coming from your server for the redirect.

It had the header or "HTTP/1.1 302 Moved"

HTTP/1.0 defines the following for the 302 redirect
302 Moved Temporarily

Notice your request doesn't have "Temporarily" in it.

However HTTP/1.1 defines the following for the 302 redirect
302 Found

These are both defined in RFC2616. Browsers are trained to ignore the name and just go with the status code, however everything in between your server and the browser may not work the same way.

Also before the browser uses something from its cache it is required to make a "GET" request to the page and the server should respond with "304 Not Modified" to use the local cache or the "200 OK" with the actual content. So if neither of those happened then something really really odd is happening.

Also since these blog pages are updated an unknown intervals because of posts it should contain a header of "Cache-Control: no-cache" to tell the browser not to cache it.

I don't know what tool you are using but you may want to check to make sure it is logging everything. I personally use a tool called "Fiddler".

Sorry about the double post I just wanted to show you want I found.

Here is my request to this post:

GET /blog/archives/000955.html HTTP/1.1
Accept: */*
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; InfoPath.2)
Host: www.codinghorror.com
Proxy-Connection: Keep-Alive

Here is your servers response:

HTTP/1.1 200 OK
Connection: close
Content-Length: 10507
Date: Thu, 20 Sep 2007 00:17:08 GMT
Content-Type: text/html
Content-Encoding: gzip
ETag: "0e01e6c1bfbc71:2e1"
Server: Microsoft-IIS/6.0
Last-Modified: Thu, 20 Sep 2007 00:16:00 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding

You are going to want to set the following on the response from the server so the browser will never use cache or attempt to use cache.

Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate
Expires: -1

Hope this helps. You can really get in to header optimization for SEO purposes and to control indexing by search engines. http://coderjournal.com/2007/07/control-google-bot-with-the-new-x-robot-tag/

I visit a number of web sites (via my FF browser). When I post a comment and nothing shows, the first thing I do is reload the page. If it still doesn't show, I'll close my browser window, then go back. If neither of those work - I'll wait til later in the day. (can't tell you how often haloscan will not show a posted comment for quite a time).

So far, unless I've closed a window in the middle of posting a comment (because it was taking too long) I've never had a problem with it showing up with one of these methods... most frequently a reload is all I have to do.

I try very hard to read and find things out before I post dumb questions. Occasionally one slips through and I apologize as soon as I find out I did something stupid. *grin*

I think Zumbas got it - the root of the problem is when you initially serve the page (i.e. in response to a GET request). In this case, your web server doesn't specify any cache control directives, so Firefox is free to cache the page on disk. The cache control directives you send in response to the POST are irrelevant because Firefox already has a copy of the page cached, which it's free to use until it expires.

Maybe if the captcha wasn't always orange, people couldn't double-post.

works fine for me

Pragma, no-cache
Cache-control, private
Expires, Now() - 1

...has always been my holy triumvirate.

While you're under the hood, how about you build in some yummy Web 2.0 Digg-like comment threading? :)

> the root of the problem is when you initially serve the page (i.e. in response to a GET request). In this case, your web server doesn't specify any cache control directives, so Firefox is free to cache the page on disk

There's some really profoundly deep misunderstanding going on here about how caching works.

You only specify a cache directive if..

a) you ALWAYS want the resource to be cached and the browser to NEVER check for a new version of it until the cache duration expires. Usually this is only done for JavaScript, css, images, and other things that are unlikely to change.

b) you NEVER want the resource to be cached, and the browser to ALWAYS check for a new version. Uusually this is only done for pages that are highly dynamic and expected to be different every time per-user (eg, personalized).

What happens if you don't specify a cache directive? The browser asks if the resource has changed since it last retrieved a copy. If it has changed, it retrieves a new version of it. If it hasn't changed, the server sends a 304/not modified response back.

Not sending a cahce directive is the *default and correct behavior* you want most of the time on the web. Items a) and b) above are exceptions, not sledgehammers we apply to every page that doesn't behave the way we want.

As Niels said above:

> Examining the headers for the comments page request shows that the server doesn't send anything related to cache -- meaning the UA should always check to see if there's changes on the page with an If-Modified-Since header.

Help Prevent Lazy Web

This google search:
http://www.google.com/search?hl=en&q=prevent+browser+cache+firefox

Led me to this forum posting:
http://forums.asp.net/t/1013531.aspx

Which had this piece of advice:
"This works fine in IE & Firefox for me...

Response.Cache.SetExpires(DateTime.UtcNow.AddMinutes(-1))Response.Cache.SetCacheability(HttpCacheability.NoCache)Response.Cache.SetNoStore()

I have it in my master page code-behind. "

That should be standard to prevent browser caching.

BTW, there still is a bit of confusion regarding browser caching. If you set the expires flag on the server side to something >= 0, then most browsers will assume that the item can be safely cached for that length of time and not request it again, until that time has expired. Not even to check for a 304 response. It will blindly go to its local cache for use in rendering. This is why browser cache is so damaging to dynamic web applications and should only be used for truly static content and should otherwise be prevented.

Yeah, lazyweb only works when you have a reasonably intelligent audience, otherwise you end up with a shitpile like you have here. What you should have actually done was filed a bug, either on wordpress or firefox, and get people who know what they're doing to look at it. I have also noticed this bug, but have also been to lazy to get it fixed. But if you act now, you stand a half-decent chance of getting fixed before Firefox 3 comes out; Wordpress 2.3 is probably too far gone to debug it and get a fix in, and I can't find a timeline for 2.4 on the awful wordpress.org website.

Sidetracking a bit, it's a seriously bad website. I would have thought people making website software (i.e. a blog engine) would put more thought into it, but as it is it lacks a "Development" or "Bugs" link in the main navigation. Only the fact I remembered they used trac let me find the bug database. Also, the fact their search is seriously slow and I had better results using google site:wordpress.org doesn't help either.

It works just fine in Opera 9 for the desktop.

I looked at my Firefox about:config settings. Type "cache" into the search box. The first value is
browser.cache.check_doc_frequency = 3
which is the default value. What does this mean? Consulting the Mozilla KB, I find this description:

Possible values and their effects
0 Check for a new version of a page once per session (a session starts when the first application window opens and ends when the last application window closes).
1 Check for a new version every time a page is loaded.
2 Never check for a new version - always load the page from cache.
3 Check for a new version when the page is out of date. (Default)

When is this page out of date? That *is* the question. Without either a Cache-Control:max-age or Expires header, I don't think that answer is well-defined. If you sent Cache-Control:Max-Age=0, then the browser should always check for a new copy.

Having said all that, Firefox refreshed the page just fine for me when I posted my comment.

I already posted an explanation of what was going wrong way up the thread, but it looks as though everyone, including Jeff, missed it in the dogpile. A couple of other people also made the same point. I'm just adding another comment here in the hope that Jeff will see it this time.

Short version: You should be returning a 303 status, not 302.

For the long version, scroll up to my first post :)

Please let us know what happens when you use 303 instead of 302 in the response to the post.

My default reply to "lazyweb" questions:

http://www.justfuckinggoogleit.com/

As for the comment problem, I use FF exclusively and never had that problem.

Testing in firefox from home.

Just tested in Firefox, and I do *NOT* see the comment I just posted, above. I know it's there, of course, because Firefox failed to refresh the page.

I don't understand how this is working for anyone who uses Firefox; it's never worked for me.

As I recall, this started happening after the site went behind ISA Server 2006, but I'm unclear exactly what could be causing it.

test

test2

test

Jeff, as somebody else already pointed out, you need to do a 303 redirect not a 302.

The 303 redirect tells the browser that the POST is accepted and it should now perform a GET on the new URL.

Here is one article from my web site discussing redirects:
http://www.kirit.com/Response.Redirect%20and%20encoded%20URIs

And here is another that discusses form processing:
http://www.kirit.com/The%20%E2%80%9CCorrect%E2%80%9D%20way%20to%20process%20forms

If you check out my site you will see that it does a 303 after posting to the forums and there has never been any problem with IE or FF, not even Opera which is much more aggressive with its caching than either of the others.

All the stuff above about caching control is a complete red herring. Just use the correct redirect and it'll be fine.

Yep. Didn't refresh for me either w/ Firefox.

I am curious how it works out with the 303 vs 302...

We have an old cart app that is directed to a secondary page which adds or removes an item for a cart, and uses javascript to be returned back to the originating page. Therefore, to deal with browser caching in this situation, only the following (set in the originating page) ensures that the page is not cached at all in both IE and Firefox (sorry, only for c#...I'll check out the actual header produced later):

Response.Cache.SetCacheability(HttpCacheability.ServerAndNoCache);
Response.Cache.SetAllowResponseInBrowserHistory(false);
Response.Cache.SetNoStore();

I remember spending/wasting significant time poring over the "Lazyweb" trying to find a) a solution for this and other similar situations and b) an actual intelligent explanation. The above did for a, but I have yet to find anything that covers b. Therefore, even though this thread is slightly different from my problem scenario, it's still something that I've never been able to fully understand; I'll be reading with continued interest.

BTW, the last post did come up fine for me on FF first time. Is it normal in the US to have a leading zero for times when you use AM or PM? It isn't in the UK. Here in Thailand I see it all the time, but have always taken it to be a mistake.

TEST... sorry I forgot to put test in my comment above. And it worked as designed in firefox v. 2.0.0.7. Maybe the problem is a popular plugin or something?

lazyweb is a perfect example of the wisdom of crowds. http://tinyurl.com/3xwvq2

Came across a discussion of a similar problem that mentioned disabling the web developer toolbar, as well as installing a newer version as a solution to the Firefox caching issues. I remember an entry discussing the web developer toolbar so it caught my eye.

It seems to be working fine for me, but I do have Firefox set to automatically download and install any updates.

It works fine from here.

As others have said, use 303 for HTTP/1.1, and fall back to 302 for HTTP/1.0. Best discussion is by A. J. Flavell, sadly only available now in the wayback machine: http://web.archive.org/web/20060903033146/http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html

CherryPy has been using this approach for over two years now with zero complaints.

test - don't think i've had this problem and almost always use FF

It has worked 100% ok for me!

Matias and others, as a web developer it might seem better to just sweep it under the rug that way, but please consider the needs of the thousands of people who might use your site. Requiring every forward/back navigation to pick up a new copy of pages not only slows navigation to a crawl, it contributes to overburdening sites' cpu & bandwidth.

Off-topic.

Wow, it seems that wordpress has brougth some bad things to the blog CMS world, I see people here referring to the "unknown" CMS used for this blog when the first line in the headers posted (in red if you haven't noticed) has clearly a couple of references to Movable Type.

Maybe someone shoud make a blog post about this behaviour, or maybe not because it's just what happens due to the organic advertising going on the web today.

No problems here:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy)

no problem over here.

Works fine here. This may sound stupid, but what Firefox extensions are you running, Jeff? Could any of them be the culprit?

"Done right, Lazyweb is a part of the net public good."
beautifully said. and in retroaction it improves net itself.

Just checked it on Firefox 2.0.0.7, and the page gets refreshed correctly.

The request sent was basically the same as in the OP, and the server response was identical (except that the reason phrase was "Moved temporarely", but anyway...)

Then Firefox properly retrieved the page again:

Frame:
+ WiFi: [Unencrypted Data] .T...., (I)
+ LLC: Unnumbered(U) Frame, Command Frame, SSAP = SNAP(Sub-Network Access Protocol), DSAP = SNAP(Sub-Network Access Protocol)
+ Snap: EtherType = Internet IP (IPv4), OrgCode = XEROX CORPORATION
+ Ipv4: Next Protocol = TCP, Packet ID = 14396, Total IP Length = 696
+ Tcp: Flags=...PA..., SrcPort=59961, DstPort=HTTP(80), Len=656, Seq=1824878275 - 1824878931, Ack=263629361, Win=4051 (scale factor not found)
- Http: Request, GET /blog/archives/000955.html
- Request:
Command: GET
- URI: /blog/archives/000955.html
- Uri:
Location: /blog/archives/000955.html
ProtocolVersion: HTTP/1.1
Host: www.codinghorror.com
UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.codinghorror.com/blog/archives/000955.html
Cookie: mtcmtauth=victor; mtcmthome=http%3A//vbroto.wordpress.com
If-Modified-Since: Thu, 20 Sep 2007 07:59:01 GMT
If-None-Match: "8010e31a5cfbc71:2e1"
HeaderEnd: CRLF

Are you sure it's retrieving it from cache? Have you tried to clear the Firefox cache before submitting the comment? What happens then?

If it actually does, does somebody know if it is possible to tweak the cache behavior of Firefox?

i'm thinking 302 page moved is wrong since the page didnt actually move...

Why not redirect a user to the #id of their poset after successfully storing it? that makes the link different from what they have cached and thus will get the fresh version until browsers become smart enough to understand that 000955.html and 000955.html#comment80 are the same file. you'd have to put the comment id in every post for that tho, something you're not doing now.

You may also want to put add [code].comments-post {margin-left:20px;}[/code] to your css instead of the whole inline [code]style="margin-left:20px"[/code] you seem to have on every element, that'll save you another few bytes.

Nobody has mentioned this... users may be behind caching proxy servers. And with the 302 redirect the proxy is returning the page from its own cache. And sometimes these servers are misconfigured or simply ignore cache control flags.

Foxyshadis:
>>Matias and others... please consider the needs of the thousands of people who might use your site....overburdening sites' cpu & bandwidth....<< yadda yadda

Jeff:
>>
Not sending a cahce [sic] directive is the *default and correct behavior* you want most of the time on the web. Items a) and b) above are exceptions, not sledgehammers we apply to every page that doesn't behave the way we want.
<<

I'm sure the W3C would give you a cookie for that statement, but the web I deal with is not the stateless, unchanging, gallery that the originators intended. I work in with the web of dynamic server-controlled client behavior where highly situational things like caching are not the default, but rather something you enable after the fact, and things such as bandwidth and cpu cycles by far outpace the solutions to overcome their constraints.

My only point is that when it comes to dynamic web apps, more often than not I'd rather trade in the warm fuzzy feeling of knowing I'm saving the internet from pointless packets and cpu cycles by utilizing ultra efficient http headers that work the way god intended with the warm fuzzy feeling of of knowing that nobody will ever get an outdated page or state in any of my web apps.

Jeff you did not mention one thing, Which version of Firefox is causing the problem? or is it all random ?

>> Could it be the Firefox extensions causing a problem?

very likely i have seen weird error due to extensions and toolbars.

Works fine (albeit slowly) for me with FF 2.0.0.7 + Adblock Pro on Vista 32-bit...

I've never had the problem you've described.. not once. It takes a very long time to post, but it always refreshes afterwards.

Return a 303 instead of a 302 like suggested - see if that fixes it up on your busted machines.

Ah, I see what's happening -- the heisenberg uncertainty principle.

This entry is difficult to see the problem on, because it's changing so much through all the comments everyone is posting. If someone ELSE changes this post, your comment will also appear in Firefox. But that's a happy side-effect.

I tried a clean install of Firefox (latest download) in a XP SP2 virtual machine, and I *can* replicate the problem if I add a comment to an older post.

Trust me, the duplicate problem happens every day here, and it's specific to Firefox for some reason. I spend a lot of time cleaning up re-submitted (duplicate) comments on older posts for this very reason..

Could be some obscure configuration parameter from an old version of Firefox.

People who upgraded from the old version still have the old default value of the configuration parameter, which causes FF to use the cache.

People who has a fresh install have the new default value of the parameter, which causes FF to reload the page.

We'll see how it works for this Fresh install of FF 2.0.0.5 upgraded to FF 2.0.0.7.

Well, no problems here.

Test successful!

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

just chuck a ?just_fing_refresh=1 on the end of the url along with the POST request (I mangled the 1st version of this reply - wonder if it shows up ;) )

UPDATE: The Firefox problem is much more subtle than we thought. No real fix in sight. I'm completely unconvinced the 302/303 response codes would matter, otherwise every Movable Type install would have this problem with Firefox. I think we would have heard about that..

Instead, I modified the redirect to append the comment ID in the URL:

http://www.codinghorror.com/blog/archives/000955.html#commentid

This not only makes the URL unique, but potentially could move the view to the anchor tag for the specific comment the user just posted.

Not very elegant, but I don't think we were making any progress on determining why Firefox is doing what it's doing.

Test... sorry for the delay.. but i had to see myself...

oops.. i just realized... the workaround is in place, and so it doesn't work (or does work) for me...

I had a similar problem to this about a month ago in a program at work, and I'm nearly certain it was to do with sending the correct response code. You should at least try modifying it.

(and now I post and see whether you are already trying it :))

yeah so ?just_fing_refresh=1 *was* the fix. Fwiw I have a fun bug with the software in website link (source available from http://code.google.com/p/websiteinabox/ ) along similar lines. I'd be grateful if the lazyweb could fix it for me too please :-D

I don't want to be rude, but this seems like a very poor candidate for Lazyweb:

1. If you want to know how and why Firefox handles ambiguous HTTP situations - don't ask Lazyweb, ask the Firefox development community! If there's one thing that's clear from reading the HTTP RFCs, it's that the browser behavior in this case is open to implementation choices. For example, curl and wget certainly don't ask for user confirmation when a POST is 302'd. Firefox might. Other HTTP clients might not. Why should Lazyweb tell you how Firefox has chosen to tackle it?

2. You've received many HTTP-303 suggestions, to which your only response is "I'm completely unconvinced [it] would matter, otherwise every Movable Type install would have this problem". It also sounds like you didn't even test this solution, but are looking for a MT-specific answer. Why, then, did you ask Lazyweb in the first place, and not other MT users?

Firefox just plain sucks, thats the reason. This is not the first perculiar thing in this browser, and as usual you see the nerds saying it's correct by some rfc, it's just stupid to think rfc's holds the truth to everything, sometimes you have to actually think instead of blindly following some standard.

Hey Now Jeff,
I don't know the solution for your issue, however I've heard the team Google University & I like it since when a person searches for a few minutes most of the time the solution is there to common questions.

Coding Horror Fan,
Catto

Jeff,

Even though adding cache control to the header is a brute force method. It is something that you have to do in order to prevent these problems.

Google for google.com/ig has the following in their header.

Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate
Expires: -1

And Google isn't one to include extra stuff if it is not needed. Plus I forgot to mention this before. But there is a known problem with IIS 6.0 not refreshing the Etag which may be the cause of the problem. Because if the hash of the page isn't updated then the browser is free to use the cache. Because it looks like to the browser the page hasn't changed.

You may have not seen this problem on other MT installs because they may be running off of Apache. Just food for thought.

Nick

Do you people really have to user th 'F' word?
Or are you just too ignorant to come up with a suitable adjective?

I have two test 1 posts up above. The first one was with the default setting in FireFox for cache. The second one was changing the configuration to 1 (which is basically refresh on load). The first post i had to manually refresh the page. The second post I see as I am typing this message.

Why it worked on the second post and not the first. Seeing as though you have changed the url to include the comment id.

Do you people really have to use the 'F' word?
Or are you just too ignorant to come up with a suitable adjective?

Firefox doesn't send the fragment part of the URI to the server, so I'm guessing it probably doesn't consider it a new request and will just check the local cache. If you just add a fragment to the URI of the page you are on, it does not refresh the page. Some AJAX apps store state information in the fragment to create history entries (and preserve behaviour of the back button) as it is the only way to modify the URI in Javascript without refreshing the page. If you want the browser to make a new request, you will have to add a GET var to the query string.

C'mon people...we all know it's IIS hating on firefox.

hahaha

A quick hack could be to append a new parameter to the new URL based on the timestamp, so when you create the URL

http://www.codinghorror.com/blog/archives/000422.html, you can add something like:

http://www.codinghorror.com/blog/archives/000422.html?quick-hack=123412341232143

That way the URL will be unique, and you will get no caching issues.

It's ugly, but it could work.

Well, let's give this a try on the following Mozilla Firefox build

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

I hate to say it, but I have no trouble with Firefox 2.0.0.7, and no comments were posted in between...

A quick hack could be to append a new parameter to the new URL based on the timestamp, so when you create the URL

<a href="http://www.codinghorror.com/blog/archives/000422.html">http://www.codinghorror.com/blog/archives/000422.html</a>, you can add something like:

<a href="http://www.codinghorror.com/blog/archives/000422.html?quick-hack=123412341232143">http://www.codinghorror.com/blog/archives/000422.html?quick-hack=123412341232143</a>

That way the URL will be unique, and you will get no caching issues.

It's ugly, but it could work.

Instead of the comment number anchor being appended, how about appending:

?random_number

or

?GUID

Webcam sites use the time in milliseconds like this to make the URL unique.

Also, using either of the above will not break the URL or point to an inaccurate place(comment) instead of the top of the article, in case you are dugg or otherwise linked to without the submitter cleaning the URL for you.

Just my $0.02, as long as you are appending...

Jeff-

From the posts here, it looks like the problem may be with a particular version of firefox or a particular local setting on firefox since several posters has submitted without a duplicate.

We know that:

Firefox is only browser having problem
Problem occurs sporadically, that is, not all users or firefox encounter the problem.

So, my advice is to narrow in on a firefox user who is always having the problem, versus a firefox user who is not having the problem to see what the delta is for both users.

I've never userd Firefox so I can't help with any local settings for that product.

"I'm completely unconvinced the 302/303 response codes would matter"

Jeff, the point isn't so much whether this on its own matters, the point is that a 302 is wrong and a 303 is right. It matters not one fig what you think should matter. The UA is free to work to the letter of the protocol you use and a 302 is wrong to redirect a successful POST to a GET.

If you get odd behaviour after you correct the protocol errors then you have a valid problem, but to have a problem when you abuse the protocol is... well it's to be expected.

What you're seeing is almost certainly a conjunction of several errors, that fixing one of them doesn't stop the problem you've identified is no reason not to do the right thing.

I'm with the 302 Moved crowd.

Jeff,please just test it to prove us wrong!

'Orange' again. Quite confusing a captcha it is.
Well... am going to spam a little bit more...

"Using Firefox 1.5 caching - MDC"
http://developer.mozilla.org/en/docs/Using_Firefox_1.5_caching

Use an onbeforeunload or onunload js event handler. Works pretty well.

lazyweb.? asked intelligently, it might be a new solution, too stupidly, it is minor different duplicate and that's confusing. It is good to ask before wikipedia the terms?

> The UA is free to work to the letter of the protocol you use and a 302 is wrong to redirect a successful POST to a GET.

That's fine, but I can't quite see how to do a 303 redirect in the PERL code that makes up Movable Type.. I see a "redirect" method, but nothing low level that lets me set the http response code.

I wrote the test comment at 12:05PM above; had to hard refresh to see it using the latest FF.

Err, I got the greater and less than symbols wrong.

print redirect(-uri=<'URL',
-nph=<1,
-status=<303);

-nph is important for IIS

It's "Perl" (the language), or "perl" the binary.. not PERL.

And fat commas are written "=>" so that should be:
print redirect(-uri =>'URL',
-nph => 1,
-status => 303);

(asuming that works for MT, I dont use it).

Well, just to not follow the pack (you've already got too many cooks cross-advising you), I want to return to the initial topic, not the hidden-camera comment-stream demonstration.

I love it that I have seen two different despair.com posters in my RSS feeds in the same day. But I don't quite get this one and I guess I need it explained to me. How does lazywebbing demonstrate tacit acknowledgment that "none of us is as dumb as all of us?" It's a stretch for me to see how that works in this context.

I even did a search on the phrase, so I am not being completely lazy in my bafflement [;<). The sense of the poster is acknowledged to be something like "when people get together they often make really dumb decisions that they wouldn't have made as individuals." I am not able to connect the dots. Maybe I am trying too hard?

- Dennis

PS: The other one was about Mistakes: http://despair.com/mis24x30prin.html

I know I'm risking getting on the "bad" list, but you did invoke the LazyWeb, so you had to expect some riff-raff.

This isn't a problem for any modern website (not just blogging systems, any modern site), because they don't use html forms which post to cgi scripts which regenerate the html page and redirect back to them. Maybe it's time to give up on the Wasabi solution (MoveableType) and use a web application that leverages the past 10 years of web technology?

I think you've said in the past that you use Moveable Type because there's nothing faster than just serving raw HTML files. The problem is that, like it or not, you've built up a very active following, and you don't have a static site.

That being the case, if you used any of a number of weblog systems which store data in a database, there wouldn't be any contention on updates and you wouldn't have any redirect craziness because those systems use HTML forms the way they were designed.

I'm guessing you'll dismiss that as being too slow for a high volume blog, but I think your hunch may be wrong. For one thing, a modern system with a cache can make better use of system memory, since it can cache at a more granular level than bulky HTML files. A reluctant cache pattern could automatically add pages to cache after they break a threashold of requests per minute. The bigger deal, probably, is that the comment problems would get a lot easier.

I am a subscriber to the Rhapsody service and normally listen to music through their desktop player on my home computers. But since I am at work, and since Real is forcing a player upgrade, and the network folks here have installed the means to prevent me from doing this successfully... I attempted to log into Rhapsody through their web interface. I normally use IE6 (our firm standard) but recently installed Firefox 2.0.0.7 and thought I'd give that a shot.

Even though I was certain I was entering a correct username and password, the login continually failed. I finally gave up and attempted to create a new account just for this one login. The account registration succeeded, or so I thought, until trying to login again. It still failed. Then I remembered this whole thread...

I fired up IE6 and successfully logged in the first time. No fuss, no muss! Virtually everything is the same except for the browser. And this is a comercial site loosing potential subscribers!

I wonder if there are and Real/Rhapsody developers here at Coding Horror???

I still don't know why it's so hard to compare the current post with, say, posts in the last 5 minutes. If it's the same, you can bet your bottom dollar it's an accidental double post and ignore it.

[ICR], it's not at all, the problem is that the Movable Type Perl implementation doesn't include that feature, and I am very shy about coding in Perl. I loves me some regex, but Perl.. not so much.

As it turns out, an anchor tag (#) wasn't enough.

http://www.codinghorror.com/blog/archives/000955.html#commentid

I modified the code to add a random number to the redirect, to

http://www.codinghorror.com/blog/archives/000955.html?r=random#commentid

I hate to do this, but at least it does work in my testing.

I know in this particular case it doesn't help, but it baffles me that what seems to me is such a simple technique is so underused. I don't know of anywhere that does it, though somewhere probably does.

You said the site runs behind and ISA server... Check that the ISA server isn't caching output pages. Check the IIS server logs to ensure that there are true POST and GET and that ISA isn't "helping" by resending a cached page.

RTFM. Sorry, just joking=. I have no idea, good luck with it.

Uh, yeah bro. If the problem first occurred post ISA install then I'd look there. This jives with your postulation that "this doesn't happen on every Wordpress blog, I think we'd hear about that".

> Check the IIS server logs to ensure that there are true POST and GET and that ISA isn't "helping" by resending a cached page

I would have seen that in the sniffer trace on the wire, though.

I suppose I could try an earlier version of Firefox to see if something changed there... but it's probably best to go with the kludgey but effective "add a parameter with random value" technique at this point.

I just experienced this same issue on another site (double posting a comment) that I've never had problems with before. I went from Firefox 2.0.0.6 to 2.0.0.7 today so can't help wonder if that is related. Might just be a coincidence but I'm tempted to actually debug Firefox to see what it's doing.

works fine for me

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

Jeff Atwood: "Trust me, the duplicate problem happens every day here, and it's specific to Firefox for some reason. I spend a lot of time cleaning up re-submitted (duplicate) comments on older posts for this very reason."

This doesn't address the specific Firefox problem but...
Couldn't you just alter your code so that it compares the comment being submitted to the most recent comment for that thread and reject the second one if they are identical? Especially if they are very close in time, say the same minute or one or two minutes apart?

That way your Firefox users can hit that Post button like it owes them money but only the first one matters.

There are no stupid questions, just inquizitive idiots.

The browser (Opera 9.23) refreshed correctly after posting.

The problem that I saw was that it took like 30-45 seconds for the server to respond. Why?!

this one time at base camp i was developing with yui grids and position: relative got all messed up in ie6

and then ie6 spoke and said "I AM TEH MOST WIDESPREAD BROWSER. U MUST CONSIDER ME"

I yelled my battle cry, "I WILL L33& HAX0R YOUU!!!111" and fixed it all with pixie hacks.

That is my most exciting CSS story. - Greg

Firefox refereshed correctly after the posting , but took nearly 2 mins to refresh !!!

Cache-Control: max-age=0

that should do it.

test

I have encountered the "unwanted caching" problem..

A few people mentioned (including Jeff) a "Random" parameter... it doesn't need to be random! just use a time-stamp (it seems more elegant, and if the other string is random, it could collide LOL!)

Anyway I use ?t=[timestamp here] or &t=[timestamp here] if already some parameters.