Re: good 404 vs bad 404

The Django documentation explains it nicely: [Django] doesn’t bother to email [the admins] for 404s that don’t have a referer – those are usually just people typing in broken URLs or broken Web bots. Antonis Christ

Re: good 404 vs bad 404

I'd argue that all of the 404s are bad - if your tools are generating broken links isn't it better to fix that than to band-aid it with what is a "good" vs "bad" 404? On Thu, Mar 2, 2017 at 11:10 AM, Antonis Christofides < anto...@djangodeployment.com> wrote: > If what you want is locate broken l

Re: good 404 vs bad 404

If what you want is locate broken links and ignore 404s resulting from emails, then Django's broken link detection functionality is probably all that you need, unless you really need to do it in monitoring and you can't possibly

Re: good 404 vs bad 404

See suggestion below. On 1 March 2017 at 13:21, guettli wrote: > > Concrete example: we render HTML mails. They often contain broken links. > I don't want to report these. I would add a query string in these links to track them. E.g., "?autogenerated=1". So, links with this query string should

Re: good 404 vs bad 404

On Wednesday 01 March 2017 08:21:34 guettli wrote: > Concrete example: we render HTML mails. They often contain broken > links. I don't want to report these. That depends if the rendering makes the link broken (for example you fold soft wraps in quoted-printable incorrectly). A different approac

Re: good 404 vs bad 404

s worked well in the past. >>>> >>>> Now we have cases where a 404 is valid or should be ignored. No issue >>>> in the monitoring should be visible. >>>> >>>> You could apply "separation of concerns" and keep on reporting all 404 >>>

Re: good 404 vs bad 404

d apply "separation of concerns" and keep on reporting all 404 >>> responses >>> and do the filtering in the monitoring area. >>> >>> But on the other hand the code knows more. I have places where I know >>> that >>> this 404 sho

Re: good 404 vs bad 404

Am Mittwoch, 1. März 2017 10:54:38 UTC+1 schrieb Antonis Christofides: > > My gut feeling says you should treat this in monitoring, however here are > some questions: > > 1) Why do you monitor 404s at all? > > 2) Could you give some examples of 404s that are valid or should be > ignored? > > I

Re: good 404 vs bad 404

Am Mittwoch, 1. März 2017 10:42:44 UTC+1 schrieb Andréas Kühne: > > I think you should always report a 404 as a 404 regardless of the > situation. > > The application shouldn't have to know if it is a valid 404 or an > "invalid" - because from the applications point of view, the page (or item)

Re: good 404 vs bad 404

gt;> responses >> and do the filtering in the monitoring area. >> >> But on the other hand the code knows more. I have places where I know that >> this 404 should be ignored. >> >> I am biased where the problem should get solved: >> >> - insi

Re: good 404 vs bad 404

reporting all 404 > responses > and do the filtering in the monitoring area. > > But on the other hand the code knows more. I have places where I know that > this 404 should be ignored. > > I am biased where the problem should get solved: > >

Re: good 404 vs bad 404

s where I know that > this 404 should be ignored. > > I am biased where the problem should get solved: > > - inside django app > - inside monitoring > > > What do you think? > > Does anybody make a differenence between "good 404 vs bad 404"? > > Regards

good 404 vs bad 404

ide django app - inside monitoring What do you think? Does anybody make a differenence between "good 404 vs bad 404"? Regards, Thomas -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and