Skip to content

Commit

Permalink
Script updating archive at 2023-08-22T00:36:29Z. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Aug 22, 2023
1 parent f7f2583 commit 2615af1
Showing 1 changed file with 204 additions and 2 deletions.
206 changes: 204 additions & 2 deletions archive.json
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"magic": "E!vIA5L86J2I",
"timestamp": "2023-08-20T00:37:49.081017+00:00",
"timestamp": "2023-08-22T00:36:25.905787+00:00",
"repo": "httpwg/http-extensions",
"labels": [
{
Expand Down Expand Up @@ -58654,7 +58654,7 @@
],
"body": "I propose we ban `%00` from serialized `DisplayString`, in order to avoid a large class of security issues (and to simplify implementations) in C/POSIX environments where `0x00` is the string terminator.\r\n\r\nI can see three alternatives here.\r\n\r\n### Ban `%00` outright\r\n\r\nIn the serialization of `Display String` we add:\r\n\r\n if byte is %0x00, fail serializing.\r\n\r\nIn the parsing of `Display String we add:\r\n\r\n if octet is zero, fail parsing.\r\n\r\nIf either end uses a strict UTF-8 encoder or decoder, which do not allow \"overlong byte sequences\" (see below), this prevents `U+0000 NULL` from being transported with DisplayString.\r\n\r\n### Specify loose UTF-8 encoding & decoding\r\n\r\nJava pioneered a handling of `U+0000 NULL` by specifying that it must be UTF-8 serialized as `0xc0 + 0x80` - a so-called \"over-long UTF-8 byte sequence\".\r\n\r\nWe have presently not specified if the UTF-8 encoding of DisplayString is \"strict\" where such over-long byte sequences are illegal or \"non-strict\" where either all or a few over-long byte sequences are accepted.\r\n\r\nOver-long byte sequences _in general_ are frowned upon, because they can be used to \"obfuscate\" UTF-8 strings, for instance by encoding a period as 0xc0 0xae to try to escape directory traversal checks.\r\n\r\nWe could change the spec to say that the UTF-8 encoding/decoding must be loose (enough) to handle `U+0000 NULL` the Java-way, but I failed to identify a suitable normative reference which didnt bring in a lot of other UniCode/UTF-8 baggage we may not want.\r\n\r\n### Optimistically serialize `0x00` as `%c0%80`\r\n\r\nWe can optimistically serialize any `0x00` bytes we encounter in the encoded UTF-8 byte_array using the \"java-trick\" and leave it to the UTF-8 decoder to either reject or accept as it sees fit.\r\n\r\nIn the serialization of `DisplayString` we add:\r\n\r\n If byte is %x00 append \"%c0%80\" to encoded_string.\r\n\r\nIn the parsing of `DisplayString` we add:\r\n\r\n if octet is zero, fail parsing.\r\n\r\n### Discussion\r\n\r\nI'm a big fan of clear text and simple solutions, and I cannot imagine why anybody would ever try to send `U+0000 NULL` through a `DisplayString` for non-nefarious purposes, so I am 100% on board with simply banning `0x00` bytes in the encoded UTF-8 byte-array.\r\n\r\nBut it is a (tiny) loss of generality, and if we want to avoid that, we either make life difficult for implementers in C/POSIX based environments by rejecting this ticket, or we throw our lot with Java's handling of `U+0000 NULL` to a greater or lesser degree.\r\n\r\nOptimistically serializing `0x00`, as specified in the third alternative is a way to do that without tying ourselves to Java's mast, but it introduces some wiggle-room which, depending on ones point of view, is either desirable (allowing the receiver to reject `U+0000 NULL` by using a strict UTF-8 decoder) or undesirable (making it anyone's guess if `U+0000 NULL` can be transported in a DisplayString or not.)\r\n\r\nBut Java's handling is a bit of a hack, and allowing (some) over-long UTF-8 byte sequences introduces a class of security issues similar to the one this ticket tries to prevent, so all in all, I think we should just ban `%00` in serialized `DisplayString` with the first alternative above.\r\n\r\n\r\n\r\n\r\n",
"createdAt": "2023-08-17T05:19:34Z",
"updatedAt": "2023-08-17T22:32:50Z",
"updatedAt": "2023-08-21T13:38:23Z",
"closedAt": null,
"comments": [
{
Expand Down Expand Up @@ -58698,6 +58698,27 @@
"body": "I see no reason to single out U+0000 from other control characters. Either allow U+0000, or disallow all control characters.\r\n\r\nThe overlong encoding hack will bring more issues than it will solve.",
"createdAt": "2023-08-17T22:32:50Z",
"updatedAt": "2023-08-17T22:32:50Z"
},
{
"author": "bsdphk",
"authorAssociation": "CONTRIBUTOR",
"body": "> I see no reason to single out U+0000 from other control characters.\r\n\r\nThe only reason to single out U+0000 is that it is the string termination character in C and POSIX environments, and that is still a major cause of CVEs.\r\n\r\nI would not object to banning all the control characters, but that takes us into UniCode land which is full of dragons...\r\n\r\n> This, however, suggests a fourth option: keep the abstract data format and wire representation as-is. (All Unicode strings are allowed and `%00` is how you say U+0000.) Instead, non-normatively suggest that decoders that use a NUL-terminated in-memory representation MAY account for U+0000 by representing it as `\\xc0\\x80` in memory.\r\n\r\nThat is a third way to get the indeterminacy of the \"java-hack\", but it does have the slight benefit that the implementor of the sf-bis parser _may_ know if that over-long UTF8 sequence will work or not. However, if it does not, then nothing is gained with respect to predictability.\r\n",
"createdAt": "2023-08-20T18:48:52Z",
"updatedAt": "2023-08-20T18:48:52Z"
},
{
"author": "martinthomson",
"authorAssociation": "CONTRIBUTOR",
"body": "I'd prefer to stick with a caution here, rather than a prohibition. That means that endpoints (yes, whatever that means) can make decisions about what they tolerate, but we aren't constraining use. That is, the field can carry anything, but a resource might decide not to accept some values.",
"createdAt": "2023-08-20T21:07:48Z",
"updatedAt": "2023-08-20T21:07:48Z"
},
{
"author": "bsdphk",
"authorAssociation": "CONTRIBUTOR",
"body": "> I'd prefer to stick with a caution here, rather than a prohibition.\r\n\r\nHow about simply adding: \"UniCode category 'Cc' (Control characters) are not permitted, unless the field definition unwisely explicitly permits them.\"",
"createdAt": "2023-08-21T13:38:23Z",
"updatedAt": "2023-08-21T13:38:23Z"
}
]
},
Expand Down Expand Up @@ -154533,6 +154554,187 @@
"mergeCommit": null,
"comments": [],
"reviews": []
},
{
"number": 2617,
"id": "PR_kwDOAUA-v85YVgY8",
"title": "Rough go at moving away from 'procedures'",
"url": "https://github.com/httpwg/http-extensions/pull/2617",
"state": "OPEN",
"author": "mnot",
"authorAssociation": "MEMBER",
"assignees": [],
"labels": [],
"body": "For #2616.",
"createdAt": "2023-08-21T01:55:52Z",
"updatedAt": "2023-08-21T10:54:09Z",
"baseRepository": "httpwg/http-extensions",
"baseRefName": "main",
"baseRefOid": "c34fce42ed426aeb307fc2c7799f7f944b4f5532",
"headRepository": "httpwg/http-extensions",
"headRefName": "mnot/2616",
"headRefOid": "a02eac2f63638b51d1644bf6cdc7eb50dc8f45cf",
"closedAt": null,
"mergedAt": null,
"mergedBy": null,
"mergeCommit": null,
"comments": [],
"reviews": [
{
"id": "PRR_kwDOAUA-v85eiYn_",
"commit": {
"abbreviatedOid": "6a942e3"
},
"author": "LPardue",
"authorAssociation": "CONTRIBUTOR",
"state": "COMMENTED",
"body": "Thanks muchly for the PR. I posted a few consistency suggestion tweaks. \r\n\r\nI like how this is presented and the editorial changes don't seem too large TBH (although it might require folks that have been tracking closely so far, to spend a little time shifting their terminology model).\r\n\r\nThere's a few normative changes that were done too, that might need a bit more discussion so we're on the same page as to why.\r\n",
"createdAt": "2023-08-21T02:21:30Z",
"updatedAt": "2023-08-21T02:48:59Z",
"comments": [
{
"originalPosition": 5,
"body": "I think this is more in line with your changes\r\n\r\n```suggestion\r\nThis document defines an optional mechanism for HTTP than enables resumable uploads in a way that is backwards-compatible with conventional HTTP uploads. When an upload is interrupted, clients can send subsequent requests to query the server state and use this information to the send remaining data. Alternatively, they can cancel the upload entirely. Different from ranged downloads, this protocol does not support transferring different parts of the same representation in parallel.\r\n```",
"createdAt": "2023-08-21T02:21:30Z",
"updatedAt": "2023-08-21T02:48:39Z"
},
{
"originalPosition": 43,
"body": "```suggestion\r\n1) The client notifies the server that it wants to begin an upload ({{upload-creation}}). The server reserves the required resources to accept the upload from the client, and the client begins transferring the entire file in the request content.\r\n```",
"createdAt": "2023-08-21T02:23:35Z",
"updatedAt": "2023-08-21T02:48:39Z"
},
{
"originalPosition": 126,
"body": "This is not strictly part of this change but might make sense for consistency\r\n\r\n```suggestion\r\nIn some cases, clients might prefer to upload a file as a series of parts sent serially across multiple HTTP messages. One use case is to overcome server limits on HTTP message content size. Another use case is where the client does not know the final size, such as when file data originates from a streaming source.\r\n```",
"createdAt": "2023-08-21T02:26:29Z",
"updatedAt": "2023-08-21T02:48:39Z"
},
{
"originalPosition": 169,
"body": "Mainly flagging for my co-authors:\r\n\r\nThis looks like a normative change in the text. Is this to make it more \"HTTP-esque\" and acknowledge that the HTTP ecosystem doesn't really need the requirements around methods?",
"createdAt": "2023-08-21T02:31:09Z",
"updatedAt": "2023-08-21T02:48:39Z"
},
{
"originalPosition": 178,
"body": "```suggestion\r\nOnce the upload resource is available, the target resource MAY send an informational response with `104 (Upload Resumption Supported)` status to the client while the request content is being uploaded. In this informational response, the `Location` header field MUST be set to the upload resource.\r\n```",
"createdAt": "2023-08-21T02:32:35Z",
"updatedAt": "2023-08-21T02:48:39Z"
},
{
"originalPosition": 218,
"body": "Removal of a MUST NOT here, so flagging.",
"createdAt": "2023-08-21T02:35:50Z",
"updatedAt": "2023-08-21T02:48:39Z"
},
{
"originalPosition": 225,
"body": "```suggestion\r\nAn upload is considered complete only if the server completely and successfully received a corresponding creation ({{upload-creation}}) request or append ({{upload-appending}}) request with the `Upload-Complete` header being set to true.\r\n```",
"createdAt": "2023-08-21T02:36:49Z",
"updatedAt": "2023-08-21T02:48:39Z"
},
{
"originalPosition": 231,
"body": "```suggestion\r\nThe offset MUST be accepted by a subsequent append ({{upload-appending}}). Due to network delay and reordering, the server might still be receiving data from an ongoing transfer for the same upload resource, which in the client perspective has failed. The server MAY terminate any transfers for the same upload resource before sending the response by abruptly terminating the HTTP connection or stream. Alternatively, the server MAY keep the ongoing transfer alive but ignore further bytes received past the offset.\r\n```",
"createdAt": "2023-08-21T02:37:38Z",
"updatedAt": "2023-08-21T02:48:39Z"
},
{
"originalPosition": 313,
"body": "The deleted block is consistent with the normative changes above and so might need some discussion.",
"createdAt": "2023-08-21T02:43:51Z",
"updatedAt": "2023-08-21T02:48:39Z"
},
{
"originalPosition": 335,
"body": "```suggestion\r\nThe `301 (Moved Permanently)` status code and the `302 (Found)` status code MUST NOT be used in offset retrieval ({{offset-retrieving}}) and upload cancellation ({{upload-cancellation}}) responses. For other responses, the upload resource MAY send a `308 (Permanent Redirect)` response which clients SHOULD use for subsequent requests to it. If client receives a `307 (Temporary Redirect)` response to an offset retrieval ({{offset-retrieving}}) request, it MAY apply the redirection directly in an immediate subsequent upload append ({{upload-appending}}).\r\n```",
"createdAt": "2023-08-21T02:44:34Z",
"updatedAt": "2023-08-21T02:48:39Z"
}
]
},
{
"id": "PRR_kwDOAUA-v85eie6i",
"commit": {
"abbreviatedOid": "6a942e3"
},
"author": "mnot",
"authorAssociation": "MEMBER",
"state": "COMMENTED",
"body": "",
"createdAt": "2023-08-21T02:54:00Z",
"updatedAt": "2023-08-21T02:54:01Z",
"comments": [
{
"originalPosition": 169,
"body": "y",
"createdAt": "2023-08-21T02:54:01Z",
"updatedAt": "2023-08-21T02:54:01Z"
}
]
},
{
"id": "PRR_kwDOAUA-v85ekm85",
"commit": {
"abbreviatedOid": "6a942e3"
},
"author": "martinthomson",
"authorAssociation": "CONTRIBUTOR",
"state": "COMMENTED",
"body": "",
"createdAt": "2023-08-21T10:03:52Z",
"updatedAt": "2023-08-21T10:03:52Z",
"comments": [
{
"originalPosition": 218,
"body": "How can there be such a resource if the server doesn\u2019t support this feature?",
"createdAt": "2023-08-21T10:03:52Z",
"updatedAt": "2023-08-21T10:03:52Z"
}
]
},
{
"id": "PRR_kwDOAUA-v85eknag",
"commit": {
"abbreviatedOid": "6a942e3"
},
"author": "martinthomson",
"authorAssociation": "CONTRIBUTOR",
"state": "COMMENTED",
"body": "",
"createdAt": "2023-08-21T10:05:02Z",
"updatedAt": "2023-08-21T10:05:02Z",
"comments": [
{
"originalPosition": 169,
"body": "\u201cthat are supported\u201d?",
"createdAt": "2023-08-21T10:05:02Z",
"updatedAt": "2023-08-21T10:05:02Z"
}
]
},
{
"id": "PRR_kwDOAUA-v85ek5z0",
"commit": {
"abbreviatedOid": "6a942e3"
},
"author": "mnot",
"authorAssociation": "MEMBER",
"state": "COMMENTED",
"body": "",
"createdAt": "2023-08-21T10:54:08Z",
"updatedAt": "2023-08-21T10:54:09Z",
"comments": [
{
"originalPosition": 218,
"body": "Is that specific to this pr?",
"createdAt": "2023-08-21T10:54:08Z",
"updatedAt": "2023-08-21T10:54:09Z"
}
]
}
]
}
]
}

0 comments on commit 2615af1

Please sign in to comment.