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 before a function that potentially errors-out, then resetting it back to 200 afterwards, is the correct fix. On 6/9/17, kowlsd3pw...@yahoo.co.jp <kowlsd3pw...@yahoo.co.jp> wrote: > /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&name=12c010669a95d634 > src/tar.c : tarball_page function > > https://www.fossil-scm.org/index.html/artifact?ln=714&name=17b09ed44d15326d > > Since name_to_typed_rid calls fossil_fatal, it needs to call cgi_set_status > before that. > > + cgi_set_status(404, "Not Found"); > rid = name_to_typed_rid(nRid?zRid:zName, "ci"); > if.. > .. > } > + cgi_set_status(200, "OK"); -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
