post.php strangeness

If it’s a ‘bad server response’ the problem lies there.
See if it rectifies itself after a while.

Well, it’s been going on for a few months already. :/

Check your server error logs.

My server admin says “there’s nothing at all in the error logs that appears related to this.” Is there anything specific I should have him look for? I made about 10 test posts this morning; I would think something would show up. (He does, though, say “if you want to figure this out later, let me know and i’ll capture the network traffic and look.” So that’s the next step, I guess.)
Has anyone else run into this?

Go ahead and take the “next step”. That’ll help narrow it down.

Wow, that is a mouth full of problems. Have you tried deleting post.php and replacing it with a fresh one? I suppose that might help. It won’t harm anything.

Hmm. Wouldn’t it have been replaced already when I installed 1.2.1? That didn’t fix it. But I could try.
Update: When I tested today the error was back. The admin looked at the server and said “whaddayaknow, there’s a spinning apache process.” So he’s restarting the server. He says that this problem — apache processes getting stuck — has been going on for some time (hence so many apache restarts in the last few months), so maybe that is the cause of my WP problem. However, he has been unable to figure out what triggers the problem. If anyone has any suggestions in that area I would love to hear them.
As far as replacing the post.php, my gut tells me it won’t make a difference, but like you said, it shouldn’t hurt anything either, so I will try to do that.

Heh. We are hosting the site ourselves on our own web server. There is no other server to move to. The “server admin” is my charming spouse, Jason. ?? (It’s just easier to call him the “admin” when making support queries, since he’s the one who does the server administration around here.) There is a lot of stuff running on the server, though, not just the blog, and not just our own personal stuff. So, yeah, it could be anything. And Jason’s been trying to figure it out for ages, since well before we started trying to fix the WordPress problem.
He just disabled mod_gzip again, so we’ll see if the problem reoccurs.

Heh, you made it sound so professional. I thought you were with a hosting company.

Nah, that’s no fun!
So far the error hasn’t returned since disabling mod_gzip. I am keeping my fingers crossed.
Incidentally this problem sounds kind of similar.

The problem is back, so it’s probably not mod_gzip at fault.

Um. That was me.

I’ve been experiencing the same problem, but first noticed it with sending mail in Squirrelmail using Firefox. I’d hit “Send” and it would seem to submit but then stop, and then I’d see the email sent three times in my Sent folder. Thinking the problem might be with Firefox, I switched to Safari and eventually received the same error you mentioned (which is how I found this thread).
I don’t have mod_gzip running on my server, but since Squirrelmail uses PHP I’d assume the problem lies there.

I have further information.
A couple of days ago (I think it was Nov 13) Jason disabled apc, a php caching application.
Since then the error has not returned, and outgoing trackbacks and pings are consistently working.
This is notable because before this, the error would always return after less than a day (not sure HOW much less). So this is a possible fix. I’ll keep an eye on it and post if I find out more.
Any comments?

In the squirrelmail case, I think the problem might have been due to my inbox being atypically large and causing the imap connection to overload PHP’s memory bounds. I noticed this error message in my apache logs when getting the error in Safari:
[Wed Nov 17 19:02:17 2004] [error] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 44 bytes) in /usr/local/www/squirrelmail/src/compose.php on line 775
At first I dismissed this as being due to some tight loop that PHP was getting itself stuck in, since I couldn’t imagine any legitimate reason why it would be using that much memory. But then I noticed that the problem was occurring with increasing frequency, and it finally dawned on me that it might be related to the size of my inbox (which I assume is impacting how much memory the imap functions use when reading in the message headers).
I cleared out some messages — and the problem went away.
In thinking about this more, I suspect we may not be experiencing exactly the same problem. The identical Safari error message and the fact that we were both seeing triple-postings (in my case email, in your case WP posts) made me think the problems were related, but it could just be PHP crashing in both cases for completely different reasons, producing identical results in our browsers. I suspect that Firefox/Mozilla will try three times if it gets an abnormal connection close from the server, before it gives up, and that’s why we’re seeing the triple posts.
-Bill Clark