Re: [fossil-users] bug : /zip or /tar error page response return HTTP/1.1 200 OK

2017-06-09 Thread Ross Berteig
On 6/9/2017 1:26 PM, Warren Young wrote: On Jun 9, 2017, at 7:11 AM, Richard Hipp wrote: Perhaps /tarball and /zip are special in the sense that they are often accessed by scripts. I don’t have any data on whether that is true, but you are right that /webpages frequently

Re: [fossil-users] bug : /zip or /tar error page response return HTTP/1.1 200 OK

2017-06-09 Thread Warren Young
On Jun 9, 2017, at 7:11 AM, Richard Hipp wrote: > > Perhaps /tarball and /zip are special in the sense that they are often > accessed by scripts. I don’t have any data on whether that is true, but you are right that /webpages frequently accessed by scripts should return

Re: [fossil-users] bug : /zip or /tar error page response return HTTP/1.1 200 OK

2017-06-09 Thread Richard Hipp
On 6/9/17, Stephan Beal wrote: > > Perhaps name_to_typed_rid() should set it to 404 IF running in [non-json] > http mode? (For JSON, the API currently returns 200 everywhere and uses its > own error codes to report what went wrong. That behaviour is arguable but >

Re: [fossil-users] bug : /zip or /tar error page response return HTTP/1.1 200 OK

2017-06-09 Thread Stephan Beal
On Fri, Jun 9, 2017 at 2:01 PM, Richard Hipp wrote: > I think there are many other examples where Fossil finds incorrect > query parameters and reports an error in text, but still returns "200 > ok". If returning a non-200 result codes on an error is important, > then we have a

Re: [fossil-users] bug : /zip or /tar error page response return HTTP/1.1 200 OK

2017-06-09 Thread Richard Hipp
I think there are many other examples where Fossil finds incorrect query parameters and reports an error in text, but still returns "200 ok". If returning a non-200 result codes on an error is important, then we have a lot of clean-up to do. Also, I'm not sure setting the result code to an error