The problem is with redirects. For some reason, early versions of Safari (pre 2) don't follow our redirects.

The simplest reproduction of the problem is:

http://news.ycombinator.com/safaritest

which redirects to apple.com in other browsers but generates an error in early versions of Safari.

I'd be very grateful if any Safari expert out there could tell me what's going wrong.

Problem solved. The source of the trouble is that early versions of Safari insist on a blank line after the Location header in a redirect. Thanks to Trevor Blackwell for proposing this.

In the latest release, everything seems to work, at least in Safari 1.3.

Every time I submit (story/comment) or delete, the /r page comes back as "This page can't be found" in Safari. All of the POSTs are submitting, I just don't get results back. Dunno if it's just me.

Yeah, looks like there is some kind of problem. It looks like some arguments (specifically the fnid argument) may not be getting sent to the server in form submissions, though Firefox and Explorer do send this argument. Any Safari experts have any idea what might be going on?

Edit: The args arrive fine. The prob may be with the redirect after the form submission. The main difference I see in requests from Firefox and Safari is that F says Connection: keep-alive and S says Connection: close.

Edit 2: The prob is with redirects, not forms. But I'm not sure why, and it doesn't happen in more recent versions of Safari.

Never used Safari. I've examined the network packets though and there's some non-standard stuff going on when using Firefox.

HTTP/1.0 302 Moved

Date: Fri, 15 Jun 2007 15:40:40 GMT

Location: item?id=28352

The Location header should have an absolute URI: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30

Also, you're using a 302 response to a POST request which, strictly speaking, means the browser should re-do the POST to the new URI in the Location header. Many don't, they do a GET instead. The 303 response can be used to say you insist they GET the new URI despite the original being a POST. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3

Just noticed you're using HTTP/1.0. I've referred you to 1.1. You may wish to switch.

I don't see why Safari saying it doesn't want to keep the connection open should matter. You turn down Firefox's request anyway and close the connection, don't you?

Do people using the most recent versions of Safari notice any problems logging in or submitting forms? I ask because I'm surprised no one reported this before. I can reproduce it in the Safari I have, but it's old (1.3.2).

Update: In fact it looks the site works fine in version 2 and later.

Does that mean you're not going to fix the Location header and the other standards non-compliance?

News.YC doesn't work in standard text-based browsers either at the moment. (Granted, I doubt few folks [other than uber-cli guys] use these!)

When trying to login:

links produces a "Error reading from socket" error

and

lynx produces a "Post request without Content-Length." error

Here lynx warns me that the Location URI isn't absolute. Nice of it.