I noticed you have the Live HTTP headers extension. Using that extension or Firefox's own Web Console (on Tools menu > Developer Tools), can you see whether Firefox is sending the request and not getting a response? The expected response is a redirect. If Firefox is getting the response, it then should request the /news/ page; is it failing to redirect?

If /news had a different behavior previously, Firefox might have cached it... Try clearing the cache to remove that.

(WIN) orange Firefox button (or Tools menu) > Options > Advanced
(Mac) Firefox menu > Preferences > Advanced

On the Network mini-tab > Cached Web Content : "Clear Now"

If you have a large hard drive, this might take a few minutes.

Thanks for replying. The answer is no for both questions. First, the site hasn't changed, so /new does not have any change in behavior. I did clear the cache just to be sure.

Yes, I tried looking at the HTTP headers. There was no activity. I then tailed the apache log and no activity got to it when I requested /new, but I did with /new/

It's very strange. I also tried some of the other suggestions for spinning wheel by modifying my about:config.

I am using a proxy forwarder called merb on a separate port but I can't see how that would affect things. And I'm assuming apache would still be logging this

Sorry, I should have said I tailed the application log, and in that case /new doesn't record any activity but /new/ does.

I can't think of a reason for /new to work differently than /login; Firefox should send the request.

I assume this /new URL works for you (it redirects to a language-specific URL but doesn't add a trailing slash): https://support.mozilla.org/questions/new

In case it's one of your standard extensions, could you test in Firefox's Safe Mode? That's a standard diagnostic tool to bypass interference by extensions (and some custom settings). More info: Diagnose Firefox issues using Troubleshoot Mode.

You can restart Firefox in Safe Mode using

Help > Restart with Add-ons Disabled

In the dialog, click "Start in Safe Mode" (not Reset)

Any difference in behavior?

The URL you provided works fine. Running in Safe Mode has no change in behavior. The link is simply <a href="/parks/new" style="text-decoration:underline;">Add a new park</a>

Not sure whether it's significant that it's a link. If you try one or both of these, do they work?

• right-click the link > Copy Link Location, paste it to the address bar, press Enter
• drag link and drop it onto the address bar

Try:

• https://developer.mozilla.org/en/HTTP_Logging

Jscher2000, thanks but there were no links embedded in your answer, so nothing to try.

I setup the logging successfully. Nothing outstanding or obvious here. The request is made but never completed which would follow the spinning wheel and "connecting .." If I follow the transaction session number from this line: nsHttpTransaction::Init [this=119bf1600 caps=21] I see the request on the next line, a few of these

2013-10-11 13:08:16.368123 UTC - 336072704[10032b4a0]: nsSocketInputStream::AsyncWait [this=1258730f8] 2013-10-11 13:08:16.368131 UTC - 336072704[10032b4a0]: ProcessNewTransaction Dispatch Immediately trans=119bf1600

2013-10-11 13:08:16.405226 UTC - 336072704[10032b4a0]: nsHttpTransaction::OnSocketStatus [this=119bf1600 status=804b0006 progress=180] 2013-10-11 13:08:16.405239 UTC - 336072704[10032b4a0]: nsHttpTransaction::ProcessData [this=119bf1600 count=180]

Even something that suggests success:

2013-10-11 13:08:16.405411 UTC - 336072704[10032b4a0]: nsHttpTransaction::HandleContent [this=119bf1600 count=0] 2013-10-11 13:08:16.405423 UTC - 336072704[10032b4a0]: nsHttpTransaction::HandleContentStart [this=119bf1600] 2013-10-11 13:08:16.405474 UTC - 336072704[10032b4a0]: http response [ 2013-10-11 13:08:16.405498 UTC - 336072704[10032b4a0]: HTTP/1.1 200 OK 2013-10-11 13:08:16.405510 UTC - 336072704[10032b4a0]: Date: Fri, 11 Oct 2013 13:08:16 GMT 2013-10-11 13:08:16.405520 UTC - 336072704[10032b4a0]: Server: thin 1.4.1 codename Chromeo 2013-10-11 13:08:16.405530 UTC - 336072704[10032b4a0]: Content-Type: text/html; charset=utf-8 2013-10-11 13:08:16.405540 UTC - 336072704[10032b4a0]: Connection: close 2013-10-11 13:08:16.405549 UTC - 336072704[10032b4a0]: Transfer-Encoding: chunked 2013-10-11 13:08:16.405558 UTC - 336072704[10032b4a0]: ] 2013-10-11 13:08:16.405569 UTC - 336072704[10032b4a0]: nsHttpConnection::OnHeadersAvailable [this=124322900 trans=119bf1600 response-head=1240b4100] 2013-10-11 13:08:16.405584 UTC - 336072704[10032b4a0]: Assessing red penalty to library.mskcc.org class 3 for event 131075. Penalty now 0, throttle[3] = 1000 2013-10-11 13:08:16.405598 UTC - 336072704[10032b4a0]: chunked decoder created 2013-10-11 13:08:16.405609 UTC - 336072704[10032b4a0]: nsHttpChunkedDecoder::HandleChunkedContent [count=0] 2013-10-11 13:08:16.405619 UTC - 336072704[10032b4a0]: nsHttpTransaction::HandleContent [this=119bf1600 count=0 read=0 mContentRead=0 mContentLength=-1]

More of the same, and then I just closed the browser:

2013-10-11 13:08:16.405715 UTC - 336072704[10032b4a0]: nsHttpTransaction::OnSocketStatus [this=119bf1600 status=804b0006 progress=186] 2013-10-11 13:08:16.405726 UTC - 336072704[10032b4a0]: nsHttpTransaction::ProcessData [this=119bf1600 count=6] 2013-10-11 13:08:16.405737 UTC - 336072704[10032b4a0]: nsHttpTransaction::HandleContent [this=119bf1600 count=6] 2013-10-11 13:08:16.405747 UTC - 336072704[10032b4a0]: nsHttpChunkedDecoder::HandleChunkedContent [count=6] 2013-10-11 13:08:16.405764 UTC - 336072704[10032b4a0]: nsHttpTransaction::HandleContent [this=119bf1600 count=6 read=0 mContentRead=0 mContentLength=-1] 2013-10-11 13:08:16.405777 UTC - 336072704[10032b4a0]: nsSocketInputStream::Read [this=1258730f8 count=32768] 2013-10-11 13:08:16.405787 UTC - 336072704[10032b4a0]: calling PR_Read [count=32768] 2013-10-11 13:08:16.405973 UTC - 336072704[10032b4a0]: PR_Read returned [n=6723] 2013-10-11 13:08:16.405987 UTC - 336072704[10032b4a0]: nsSocketTransport::SendStatus [this=125872fc0 status=804b0006] 2013-10-11 13:08:16.405998 UTC - 336072704[10032b4a0]: nsHttpTransaction::OnSocketStatus [this=119bf1600 status=804b0006 progress=6909] 2013-10-11 13:08:16.406009 UTC - 336072704[10032b4a0]: nsHttpTransaction::ProcessData [this=119bf1600 count=6723] 2013-10-11 13:08:16.406019 UTC - 336072704[10032b4a0]: nsHttpTransaction::HandleContent [this=119bf1600 count=6723] 2013-10-11 13:08:16.406029 UTC - 336072704[10032b4a0]: nsHttpChunkedDecoder::HandleChunkedContent [count=6723] 2013-10-11 13:08:16.406039 UTC - 336072704[10032b4a0]: nsHttpTransaction::HandleContent [this=119bf1600 count=6723 read=6723 mContentRead=6723 mContentLength=-1] 2013-10-11 13:08:16.406051 UTC - 336072704[10032b4a0]: nsSocketInputStream::Read [this=1258730f8 count=26045] 2013-10-11 13:08:16.406061 UTC - 336072704[10032b4a0]: calling PR_Read [count=26045] 2013-10-11 13:08:16.406093 UTC - 336072704[10032b4a0]: PR_Read returned [n=2] 2013-10-11 13:08:16.406105 UTC - 336072704[10032b4a0]: nsSocketTransport::SendStatus [this=125872fc0 status=804b0006] 2013-10-11 13:08:16.406116 UTC - 336072704[10032b4a0]: nsHttpTransaction::OnSocketStatus [this=119bf1600 status=804b0006 progress=6911] 2013-10-11 13:08:16.406128 UTC - 336072704[10032b4a0]: nsHttpTransaction::ProcessData [this=119bf1600 count=2] 2013-10-11 13:08:16.406138 UTC - 336072704[10032b4a0]: nsHttpTransaction::HandleContent [this=119bf1600 count=2] 2013-10-11 13:08:16.406167 UTC - 336072704[10032b4a0]: nsHttpChunkedDecoder::HandleChunkedContent [count=2] 2013-10-11 13:08:16.406178 UTC - 336072704[10032b4a0]: nsHttpTransaction::HandleContent [this=119bf1600 count=2 read=0 mContentRead=6723 mContentLength=-1] 2013-10-11 13:08:16.406205 UTC - 336072704[10032b4a0]: nsSocketInputStream::Read [this=1258730f8 count=26045] 2013-10-11 13:08:16.406216 UTC - 336072704[10032b4a0]: calling PR_Read [count=26045] 2013-10-11 13:08:16.406252 UTC - 336072704[10032b4a0]: PR_Read returned [n=5] 2013-10-11 13:08:16.406264 UTC - 336072704[10032b4a0]: nsSocketTransport::SendStatus [this=125872fc0 status=804b0006] 2013-10-11 13:08:16.406275 UTC - 336072704[10032b4a0]: nsHttpTransaction::OnSocketStatus [this=119bf1600 status=804b0006 progress=6916] 2013-10-11 13:08:16.406287 UTC - 336072704[10032b4a0]: nsHttpTransaction::ProcessData [this=119bf1600 count=5] 2013-10-11 13:08:16.406297 UTC - 336072704[10032b4a0]: nsHttpTransaction::HandleContent [this=119bf1600 count=5] 2013-10-11 13:08:16.406307 UTC - 336072704[10032b4a0]: nsHttpChunkedDecoder::HandleChunkedContent [count=5] 2013-10-11 13:08:16.406319 UTC - 336072704[10032b4a0]: reached end of chunked-body 2013-10-11 13:08:16.406329 UTC - 336072704[10032b4a0]: nsHttpTransaction::HandleContent [this=119bf1600 count=5 read=0 mContentRead=6723 mContentLength=-1] 2013-10-11 13:08:16.406342 UTC - 336072704[10032b4a0]: nsHttpConnection::CloseTransaction[this=124322900 trans=19bf1600 reason=80470002] 2013-10-11 13:08:16.406353 UTC - 336072704[10032b4a0]: nsHttpTransaction::Close [this=119bf1600 reason=0] 2013-10-11 13:08:16.406364 UTC - 336072704[10032b4a0]: nsHttpConnectionMgr::ReclaimConnection [conn=24322900] 2013-10-11 13:08:16.406382 UTC - 336072704[10032b4a0]: STS dispatch [11fe33cc0] 2013-10-11 13:08:16.406420 UTC - 336072704[10032b4a0]: nsHttpConnectionMgr::OnMsgReclaimConnection [conn=124322900] 2013-10-11 13:08:16.406435 UTC - 336072704[10032b4a0]: nsHttpConnectionMgr::ConditionallyStopTimeoutTick armed=1 active=1 2013-10-11 13:08:16.406446 UTC - 336072704[10032b4a0]: connection cannot be reused; closing connection

Hi restlest, sorry that wasn't clear, I was referring to the link in your page.

Of course. Sorry. A bit dense on my part.

The second, dragging the link doesn't work. The first, copying link location, for some reason adds the forward slash in the address bar and highlights the slash. I'm not clear why it's adding the slash, and I cleared my cache to make sure it wasn't picking that up. At any rate, it does resolve because of the added slash. I'm not sure what that tells us?

Hi restlest, I think the added slash in the address bar when you paste is caused by the "autofill" feature. If you delete that slash and press Enter, it probably will time out the same way as the other two methods.

I'm a little puzzled that your log data shows a 200 response, indicating that the server has sent you a page instead of a redirect, but I'm not sure I'm reading it correctly.