-
Notifications
You must be signed in to change notification settings - Fork 155
Stop rewriting 404s #170
Comments
It may make sense to revisit this. 404 pages are often relatively rich, with lots to optimize. Neither the introduction of PLT beacons nor the DOS attack reasoning makes much sense to me. Is there any other reason to keep this restriction? |
My 4 year old memory is a bit fuzzy on this :) but the reasoning I remember is: A) We do not expect much content on 404s, B) We don't expect high percentage of traffic to be for 404, C) We really don't want to break 404 pages (ex: somehow obfuscate the error message). But if we're not worried about (C), then maybe there's no harm. I certainly don't feel strongly and think it would be fine if we changed this back. |
On Mon, Jun 15, 2015 at 5:39 PM, Shawn Ligocki notifications@github.com
Arguably we should actually be replacing some 404 pages with
|
I don't think this is something we could do by default. Many sites use their 404 pages to offer people suggestions about how to find what they're looking for. I do think 0-length 404s would be good for |
Note that there are practical difficulties rewriting 404s on Apache 2.4 IIRC it implements AddOutputFilterByType in mod_filter (2.2 had a static apr_status_t filter_harness(ap_filter_t *f, apr_bucket_brigade *bb)
... I guess the |
Original issue reported on code.google.com by
sligocki@google.com
on 30 Dec 2010 at 9:28The text was updated successfully, but these errors were encountered: