Re: [fossil-users] "fossil http" doubts

On Jun 9, 2017, at 12:17 PM, Ross Berteig wrote: > > I do think that the JSON support is close to solid enough to be on by default. For functionality alone, that is surely true, but in the face of malice? Parsers are notoriously difficult to make bomb-proof. Even if the

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

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

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] "fossil http" doubts

On 6/9/2017 1:21 PM, Warren Young wrote: On Jun 9, 2017, at 12:17 PM, Ross Berteig wrote: I do think that the JSON support is close to solid enough to be on by default. For functionality alone, that is surely true, but in the face of malice? Parsers are notoriously

Re: [fossil-users] "fossil http" doubts

> A test case that validates all of the HTML output would be great. That > should be content agnostic, of course, so that it can be maintained without > requiring a lot of work for new versions. IMHO, the W3C HTML Validator https://validator.w3.org/ has always done a good job for validating

Re: [fossil-users] "fossil http" doubts

> A test case that validates all of the HTML output would be great. That > should be content agnostic, of course, so that it can be maintained without > requiring a lot of work for new versions. IMHO, the W3C HTML Validator https://validator.w3.org/ has always done a good job for validating

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

/zip/?r=error-tag-name this error page return HTTP/1.1 200 OK. src/zip.c : baseline_zip_page function   https://www.fossil-scm.org/index.html/artifact?ln=570=12c010669a95d634 src/tar.c : tarball_page function   https://www.fossil-scm.org/index.html/artifact?ln=714=17b09ed44d15326d Since

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

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

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

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

Re: [fossil-users] "fossil http" doubts

On 6/8/2017 9:17 PM, Stephan Beal wrote: On Thu, Jun 8, 2017 at 10:43 PM, Ross Berteig > wrote: For building tools to generally interact with a repo, take a look at the JSON support. It's (still) not compiled in by default, but