404 from session/current.json

(Zach Gambill) #1

Googlebot found the GET request for session/current.json (see meta.discourse.org/session/current.json as an example) on our site and tried to access the page. We found this marked as a 404 in Search Console.

It looks like this gives a 404 if the visitor is not a logged-in user, which seems like an odd response here. Is there an easy fix for this? Or is a fix coming in a discourse release sometime soon?

(Mittineague) #2

What response code are you thinking would be more appropriate?

If a request is made by a not-logged-in, it follows there won’t be a session. So a 404 seems good to me, but I am interested in hearing alternatives.

(Zach Gambill) #3

I can see where you’re coming from. Describing this as a session not existing makes the thought process a bit clearer.

I’m definitely not an expert on proper usage of response codes, but wouldn’t a 401 or 403 for unauthorized request/access denied be a better response here? Or a 200 with stripped out data? This is a request being issued for every visitor, the majority of which will return 404s (at least for public sites).

(Mittineague) #4

I’m curious where this link is located.

In any case I don’t think an Unauthorized, Forbidden, or OK are good fits. IMHO, if anything other than a Not Found (for a non-existing) it would be a Not Implemented


10.5.2 501 Not Implemented

The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.

(Jeff Atwood) #5

Hmm shouldn’t our improved robots.txt prevent this now @sam?

(Sam Saffron) #6

Thing is /session is already disallowed per: discourse/robots_txt_controller.rb at df815d6c0e8312f5a08c1fc531ed7e5a5e61ff43 · discourse/discourse · GitHub

  • subfolder install with missing robots.txt

  • one of the crazy cases where we you have to also return an noindex meta tag or something, though I think 404 is OK here.