Use the canonical form with index.php, this is a safety issue for old IE security bugs with type sniffing.

Both locally on master, mediawiki.org and on en.wikipedia.org, I can't reproduce a user-facing exception for this type of url. And its been that way for at least 5 years I think.

It generates a Forbidden page:

It's technically implemented as an HttpError(Exception) with a report method to render the Forbidden page. And MWExceptionHandler logs it as it would any other exception. Perhaps we should disable logging of HttpError exceptions. Similarly as PermissionsError exceptions (though I'm not certain we aren't logging those either). Or should we log them in some cases?

I doubt this has been all over the exception logs for years... These should probably be caught somewhere. I'm not seeing PermissionsErrors exceptions come up in the log if I try to browse to Special:HideRevision on enwiki.

In T89377#1035202, @brion wrote:

I recommend fixing RawPage to catch the exception and link to the preferred URL; this has been reported several timed over the years and seems to confuse people with the unclear failure mode.

If we have a preferred URL, why not have IEUrlExtension::fixUrlForIE6() return it to use the existing code path that redirects the request instead of showing any error?

In T89377#1037469, @Anomie wrote:

If we have a preferred URL, why not have IEUrlExtension::fixUrlForIE6() return it to use the existing code path that redirects the request instead of showing any error?

Hmmmmmmm, that should work actually I think. I'll whip up an old IE VM and double-check the behavior.

In T89377#1035234, @Krinkle wrote:

It's technically implemented as an HttpError(Exception) with a report method to render the Forbidden page. And MWExceptionHandler logs it as it would any other exception. Perhaps we should disable logging of HttpError exceptions. Similarly as PermissionsError exceptions (though I'm not certain we aren't logging those either). Or should we log them in some cases?

PermissionsError, being an ErrorPageError exception, would be caught by MediaWiki::run() and handled specially there. HttpError isn't an ErrorPageError, presumably because that expects i18n messages and so on while HttpError seems to be intended to be lower-level.

Ok, looks like IEUrlExtension::fixUrlForIE6() doesn't know how to decompose the title or action or whatever from the URL... not sure how tricky it would be to retrofit on that end without introducing MW dependencies into the library code.

In T89377#1035200, @brion wrote:

Use the canonical form with index.php, this is a safety issue for old IE security bugs with type sniffing.

Considering we've already killed support for such browsers at WMF, is this still worth even detecting and defending against?