> As for distinguishing between GET and POST requests, `content-length` in the request line effectively does, doesn't it? The only use a separate indicator would enable is zero-byte POST.
Perhaps I was unclear, because it is not quite what I meant. What I meant is GET requests with query strings vs POST requests. That is what Spartan does not. distinguish. It does distinguish POST requests from requests with no data, but it is not what I meant.
> Making requests ASCII seems like a good idea, too. It means old computers can support the full protocol without implementing Unicode.
Yes, I also think that it is a good idea. (However, implementing Unicode is not really necessary for a client to send requests anyways (which is the case even if the request is UTF-8, although specifying that requests are ASCII seems cleaner and better to me). The more important part is that the request does not use Unicode domain names and sends them in ASCII format instead, and that the server accepts this and does not expect Unicode requests.)
> One problem with HTTP/1.1 headers is that they are deceptively simple. Processing them correctly requires handling letter case, leading and trailing whitespace, duplicate field names, and fields that span multiple lines. (A line the starts with a space or tab continues the previous.)
I agree with this, they are the problems with the HTTP header format, and it is what I had thought too. However, there is also the consideration of, should you really need so many headers anyways?
> What I meant is GET requests with query strings vs POST requests.
Oh, I see.
Yes, I would say that, conceptually, Spartan doesn't have GET requests with a query; it only has GET without a query and POST.
`=:` is like HTML `<form action="post">`.
If you wanted to add queries to Spartan, you would probably do it without breaking compatibility by parsing the query out of `path-absolute`.
For example:
example.com /weather?city=lisbon&time=tomorrow 0
The downside is that it would drag in part of URL parsing on the server, which the protocol currently avoids.
> However, there is also the consideration of, should you really need so many headers anyways?
I see it not as a matter of number but change over time.
Headers leave room for protocol evolution and extension.
You could also have evolution with protocol versions.
A caveat is that if you ever go from sequential versions like 1.2 to versions that enumerate features like 1.2+foo+bar,
you end up in a similar place to headers.
Compared to headers, you get more flexibility in protocol parsing and a more ad hoc design.
Most of your features probably don't need the flexibility, so you just pay the cost of an ad hoc design.
(For example, `+foo` and `+bar` may each add a field to the request line.
You'd have to make sure they didn't conflict.)
> I have added it to the list of mirrors at the bottom of the file.
Perhaps I was unclear, because it is not quite what I meant. What I meant is GET requests with query strings vs POST requests. That is what Spartan does not. distinguish. It does distinguish POST requests from requests with no data, but it is not what I meant.
> Making requests ASCII seems like a good idea, too. It means old computers can support the full protocol without implementing Unicode.
Yes, I also think that it is a good idea. (However, implementing Unicode is not really necessary for a client to send requests anyways (which is the case even if the request is UTF-8, although specifying that requests are ASCII seems cleaner and better to me). The more important part is that the request does not use Unicode domain names and sends them in ASCII format instead, and that the server accepts this and does not expect Unicode requests.)
> One problem with HTTP/1.1 headers is that they are deceptively simple. Processing them correctly requires handling letter case, leading and trailing whitespace, duplicate field names, and fields that span multiple lines. (A line the starts with a space or tab continues the previous.)
I agree with this, they are the problems with the HTTP header format, and it is what I had thought too. However, there is also the consideration of, should you really need so many headers anyways?
> Since you support it anyway, I have mirrored the file at https://dbohdan.com/mirror/scorpion/zzo38computer.org/smallw...
I have added it to the list of mirrors at the bottom of the file.