Maniphest T19042

talk links should never send user to a 404
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• bzimport
	Jan 16 2009, 10:55 PM

Description

Author: herd

Description:
As some ISPs and possibly some esoteric browsers still usurp 404 messages, a 404 status code should never be served as the result of a Search. For example, if you put in User:Someuser where the user exists but has no user page, you are automatically taken to the user page, but given a 404. If their ISP/Browser sucks, they then can't check the user's contribs or talk page.

The same logic that applies the redirects should possibly also be used to determine the status (in a mutually exclusive way).

Annoying, incoming interwiki links probably cannot be handled correctly, without referer sniffing.

Version: 1.15.x
Severity: enhancement

Details

Reference: bz17042

Event Timeline

• bzimport raised the priority of this task from to Low.Nov 21 2014, 10:26 PM

• bzimport added a project: MediaWiki-User-Interface.

• bzimport set Reference to bz17042.

• bzimport added a subscriber: Unknown Object (MLST).

• bzimport created this task.Jan 16 2009, 10:55 PM

On general principle, probably should not be returning a 404 for a user page for an existing user/IP address.

herd wrote:

(In reply to comment #1)

On general principle, probably should not be returning a 404 for a user page
for an existing user/IP address.

Updating summary for more accuracy.

This can be resolved by either not sending users to these via Search [go] and p-personal link clicking, /or/ by not serving 404 for them (as per populated red categories or shared repository images).

Note that either all user/user_talk pages will have to check if the user exists before search 30x redirects users to these pages, or 404 should stop being served for all user/user_talk pages (or in fact, just ditch the 404 serving completely).

Meno25 unsubscribed.Jan 17 2017, 3:53 PM

https://en.wikipedia.org/w/index.php?title=User%3ARWBIII_22 gives be HTTP 200 despite page not existing so I am assuming this is resolved.

internal http redirects (from search [go] for user/user_talk) and existing user/talk links should never send user to a 404Closed, ResolvedPublicActions

Description

Details

Event Timeline

internal http redirects (from search [go] for user/user_talk) and existing user/talk links should never send user to a 404
Closed, ResolvedPublic
Actions