which is invalid since it's missing the request-target part of the request.

It's not invalid for HTTP/1.0 which doesn't require a version if the request is a "Simple-Request". I'm not sure there's a compelling reason to "fix" this in Fossil. The only thing that is quirky about Fossil's response is how it reports the PATH as "TTP" instead of "HTTP". That's due to this line:

https://fossil-scm.org/home/file?ci=trunk&name=src%2Fmain.c&ln=2118

Perhaps it should not assume that path begins with '/' and only skip the first char of zPath if it does? Then you would get an error that looks like:

HTTP/1.0 404 Not Found Date: Thu, 12 Mar 2026 04:00:51 +0000 Connection: close X-UA-Compatible: IE=edge Cache-control: no-cache X-Frame-Options: SAMEORIGIN Content-Type: text/html; charset=utf-8 Content-Length: 47

Not Found

Page not found: HTTP

I spent a bit of time yesterday trawling the RFCs trying to confirm my faint recollection that the version part is optional and therefore that the 'HTTP/1.0' should in fact be taken as a 'request-target' not a 'HTTP-version'. Sadly I did not find anything definitive so gave up.

What I am fairly sure of though is that the leading '/' is not optional. This is HTTP protocal, not HTML: when you click on href="z" on a page "/x/y" it is the browser not the server which which turns this into "/x/z". HTTP is stateless, it has no idea what the current page is so cannot do relative references.

My best guess is that Fossil allows / to be left out in order to accomodate some broken client from the dim and distant past, as you say it is trying to find '/HTTP/1.0'.

So should Fossil stay as it is, report bad request (because of the missing / rather than working out that the first argument looks like a version), or stop removing the / from the message (even when it isn't there). The argument for the last option is that somebody who knows the protocal might be misled by a message which has removed a / that they know should be there, and waste time looking for the missing / when in fact there is a typo somewhere else in the URL.

My vote may vary according to who does the work...

Trevor

I spent a bit of time yesterday trawling the RFCs trying to confirm my faint recollection that the version part is optional

See: https://www.rfc-editor.org/rfc/rfc1945.html#section-5

Specifically the description of a Simple-Request, however, in reading that I'm not sure Fossil needs to support HTTP/0.9 clients in this way. If not, then it would be simpler to just return a 400 Bad Request if there are not 3 tokens found on the Request-Line.

I had working code for this but then doubted whether or not it was correct because I'm not sure what it might break, however, I'm also doubtful at this point that Fossil generates a response that conforms to HTTP/0.9. So I opted for the alternative which was to make Fossil first check for '/' and not assume it is there so that it could at least return a more sensible error than "TTP".

If Fossil shouldn't or cannot easily support the Simple-Request as documented, then I'll commit my change that returns an error if there are not 3 tokens in the Request-Line.

Keep in mind that this particular behavior of Fossil has been there since the dawn of Fossil history---I'm not saying it makes it correct, just that I don't recall ever having an actual problem come of it.

I don't recall ever having an actual problem come of it.

Exactly. If it ain't broke, don't fix it.

To amplify: This is not a case of Fossil responding incorrectly to a well-formed HTTP request. The issue here is Fossil giving a goofy, though harmless, reply to a ill-formed HTTP request. The current HTTP implementation has been working great for 18 years. Let's not risk breaking it, or slowing it down, to fix something that isn't really a problem.

That's fine, it can be left alone. For the archives, if ever we want to revist it, RFC 1945 defines abs_path [1] as:

   abs_path       = "/" rel_path

It further defines Request-Uri [2] as:

   Request-URI    = absoluteURI | abs_path

Which means that in the second form of Request-URI, the path must necessarily always begin with with a '/' character. This must be why Fossil assumes that there is a slash and skips it without first validating it, resulting in a truncated path of "TTP" instead of "HTTP" in the error condition.

[1] https://www.rfc-editor.org/rfc/rfc1945.html#section-3.2.1 [2] https://www.rfc-editor.org/rfc/rfc1945.html#section-5.1.2

Given that, my proposed change would be merely:

g.zPath = (zPath[0] && zPath[0]=='/') ? &zPath[1] : &zPath[0];

To replace line 2118 here:

https://fossil-scm.org/home/file?ci=trunk&name=src%2Fmain.c&ln=2118