- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 4 Aug 2022 08:56:53 +0200
- To: ietf-http-wg@w3.org
Am 03.08.2022 um 22:36 schrieb Austin William Wright: > ... > Hi Julian, > > I don’t have terribly strong opinions about what the format is, but this is what I thought was obvious based on a few motivations: > > 1. It re-uses an existing parser (it’s an off-the-shelf HTTP-message but skipping the "start-line CRLF” beginning, and is trivially parsable with a state machine or regular expression [1]). > ... That parser might be *present* everywhere, but not accessible. For instance, a Java servlet engine happily processes HTTP/1.1 messages, but doesn't provide an API to use that parser directly. > 2. It allows segments to express HTTP semantics; for example, creating a resource relies on attaching a Content-Type field. You might even attach a Digest field indicating the expected hash of the final resource. That should be on the request itself, no? > 3. It allows for some future extensions (if you omit the “Content-Range” field, you can use a different one to specify the target range). > > Would a binary format be able to accomplish this? I know there’s been some work on a binary HTTP message framing but I’m not up-to-date on this. <https://datatracker.ietf.org/doc/draft-ietf-httpbis-binary-message/> > [1] The regular expression for matching the fields a message/byterange document in draft-wright-http-patch-byterange-00 is, excluding obs- productions, is exactly: > > /^([!\x23-'\x2a\x2b\x2d\x2e0-9A-Z\x5e-z\x7c~]+:[\t ]*(?:[!-~](?:[\t -~]+[!-~])?)*[\t ]*\r\n)*\r\n/ Consider me sceptic. But I would need to dig in deeper to actually check. It would be bad to have a format that looks like HTTP/1.1 but then actually is slightly different. Best regards, Julian
Received on Thursday, 4 August 2022 06:57:33 UTC