Skip to content

Commit

Permalink
Script updating archive at 2023-08-06T00:40:41Z. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Aug 6, 2023
1 parent 1b3ad6c commit a2565ba
Showing 1 changed file with 120 additions and 9 deletions.
129 changes: 120 additions & 9 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-03T00:44:44.599742+00:00",
"timestamp": "2023-08-06T00:40:36.467276+00:00",
"repo": "httpwg/http-extensions",
"labels": [
{
Expand Down Expand Up @@ -56543,7 +56543,7 @@
"id": "I_kwDOAUA-v85ipYFy",
"title": "Reuse of the Upload-Complete header field on requests and responses",
"url": "https://github.com/httpwg/http-extensions/issues/2500",
"state": "OPEN",
"state": "CLOSED",
"author": "guoye-zhang",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
Expand All @@ -56552,8 +56552,8 @@
],
"body": "@martinthomson brought up that during the WG meeting that reusing Upload-Complete on requests and responses can be confusing. They don\u2019t mean exactly the same thing: `Upload-Complete: ?1` on the server means it has received the full upload, while `Upload-Complete: ?1` on the client means the body it will send is a complete upload.",
"createdAt": "2023-04-05T06:25:42Z",
"updatedAt": "2023-08-01T20:56:47Z",
"closedAt": null,
"updatedAt": "2023-08-04T07:32:40Z",
"closedAt": "2023-08-04T07:32:40Z",
"comments": [
{
"author": "guoye-zhang",
Expand Down Expand Up @@ -58323,7 +58323,7 @@
],
"body": "Currently, the client advertises which version it supports (e.g. `Upload-Draft-Interop-Version: 3`), and the server advertises resumable uploads if it supports that version.\r\n\r\nAs the draft evolves and introduces new values for the interop header field, clients that update to the new version lose resumable upload capabilities with a server that hasn't updated. Maybe we could define a way to advertise multiple versions to make this transition smoother.\r\n\r\nOne idea is the client could provide a list of versions it supports (e.g. `Upload-Draft-Interop-Version: 3,4`), and the server could choose one of these versions to advertise in the `104` response. However, this might not work if there's a breaking change in the discovery mechanism. For instance, if version 3 uses `Upload-Incomplete` and version 4 uses `Upload-Complete`, there's a discrepancy (we could send both?).\r\n\r\nRegardless, would we be interested in solving this multi-version issue? Does anyone have insight or experience with draft versioning like this? Thanks!",
"createdAt": "2023-07-19T23:06:51Z",
"updatedAt": "2023-07-20T01:14:35Z",
"updatedAt": "2023-08-03T14:10:27Z",
"closedAt": null,
"comments": [
{
Expand All @@ -58332,6 +58332,13 @@
"body": "It's a good question. I think the outcome will depend how how closely the implementers are working together and how responsive they can be to change.\r\n\r\nThere's a temptation to make a complex solution for something that is not intended to be shipped in the RFC. We should try to keep things simple if we can.",
"createdAt": "2023-07-20T01:14:35Z",
"updatedAt": "2023-07-20T01:14:35Z"
},
{
"author": "Acconut",
"authorAssociation": "MEMBER",
"body": "During IETF 117, we concluded that this is probably not necessary since it will only be valid while this is a draft and would make implementation not complex. I don't think we need/want this right now. Do you agree, @jrflat? If so, we could close this.",
"createdAt": "2023-08-03T14:10:26Z",
"updatedAt": "2023-08-03T14:10:26Z"
}
]
},
Expand Down Expand Up @@ -58551,6 +58558,40 @@
"updatedAt": "2023-08-02T20:51:00Z",
"closedAt": "2023-08-02T20:51:00Z",
"comments": []
},
{
"number": 2610,
"id": "I_kwDOAUA-v85tY5oQ",
"title": "Media type for Upload Appending Procedure",
"url": "https://github.com/httpwg/http-extensions/issues/2610",
"state": "OPEN",
"author": "Acconut",
"authorAssociation": "MEMBER",
"assignees": [],
"labels": [
"resumable-upload"
],
"body": "During IETF 117, it was noted that PATCH requests need to specify some media type, so our Upload Appending Procedure needs one as well. This could either be one from the byte range draft (#2501) or a custom one. For example, in the [tus uploading protocol](https://tus.io/protocols/resumable-upload) we use the content type `application/offset+octet-stream` to indicate that it is an undefined byte sequence that should be applied at a specific offset (as defined in the request). ",
"createdAt": "2023-08-03T15:03:19Z",
"updatedAt": "2023-08-03T15:03:19Z",
"closedAt": null,
"comments": []
},
{
"number": 2611,
"id": "I_kwDOAUA-v85tgDGi",
"title": "QUERY Method Status",
"url": "https://github.com/httpwg/http-extensions/issues/2611",
"state": "OPEN",
"author": "Frizlab",
"authorAssociation": "NONE",
"assignees": [],
"labels": [],
"body": "I\u2019m considering using QUERY in my API; is there a chance it becomes a standard at some point in the future or should I go with something else?\r\nI haven\u2019t seen much development regarding this method in some time now.",
"createdAt": "2023-08-04T17:34:31Z",
"updatedAt": "2023-08-04T17:34:31Z",
"closedAt": null,
"comments": []
}
],
"pulls": [
Expand Down Expand Up @@ -153680,7 +153721,7 @@
{
"number": 2595,
"id": "PR_kwDOAUA-v85V3Hl7",
"title": "Clarify handling of Content-Length and Upload-Incomplete",
"title": "Clarify handling of Content-Length and Upload-Complete",
"url": "https://github.com/httpwg/http-extensions/pull/2595",
"state": "OPEN",
"author": "Acconut",
Expand All @@ -153693,13 +153734,13 @@
],
"body": "Closes https://github.com/httpwg/http-extensions/issues/2544\r\n\r\nI am not super sure about the wording here, but this is a start. The sentences seem quite long and maybe the rules could also be expressed in fewer words.",
"createdAt": "2023-07-19T07:49:41Z",
"updatedAt": "2023-08-01T20:55:24Z",
"updatedAt": "2023-08-04T00:40:29Z",
"baseRepository": "httpwg/http-extensions",
"baseRefName": "main",
"baseRefOid": "2c50b17caffe126d2c39bf90c1a633b3b91303ff",
"headRepository": "httpwg/http-extensions",
"headRefName": "resumable-upload/content-length",
"headRefOid": "f808bdbe72c8dd4384b51f62d0b6c48ad726be07",
"headRefOid": "45eb1705b411200e5853db07c1a00643cf366c9c",
"closedAt": null,
"mergedAt": null,
"mergedBy": null,
Expand Down Expand Up @@ -153732,9 +153773,37 @@
"body": "> If the client acknowledged its final upload size at any point (`Upload-Complete: ?1` + `Content-Length`), it should still know it in the future, so I don't think we need a way for the server to echo it in the offset retrieving response. If the server disagrees with the client, then someone's data representation has changed, and we shouldn't continue the upload anyway.\r\n\r\nFair point, let's leave such functionality out of the draft.\r\n\r\n> Wondering if these could be reduced to SHOULDs though. It wouldn't really affect interop if the server didn't implement this.\r\n\r\nWhile it is true that clients usually won't really notice if the server does or does not support this, I think we can be stricter here and require this additional safety catch here. It will help to create a more standard landscape of resumable upload servers. Unless there is something against requiring this, we can keep it a MUST IMO.",
"createdAt": "2023-08-01T20:55:24Z",
"updatedAt": "2023-08-01T20:55:24Z"
},
{
"author": "Acconut",
"authorAssociation": "MEMBER",
"body": "I just updated this PR to use the Upload-Complete header as agreed on in #2500 ",
"createdAt": "2023-08-03T15:16:29Z",
"updatedAt": "2023-08-03T15:16:29Z"
},
{
"author": "guoye-zhang",
"authorAssociation": "CONTRIBUTOR",
"body": "The arguments for SHOULD are:\r\n\r\n1. This check requires additional code and complexity. MUSTs are situations that a minimal implementation has to handle anyway and we are just strict about how to handle them.\r\n2. For people using chunked uploads, this check is only useful if the last chunk is interrupted which is sort of an edge case. Maybe we can generalize the check if we adopt ranged PATCH.\r\n\r\nI don't have a strong opinion on this, so either way is OK with me.",
"createdAt": "2023-08-04T00:40:15Z",
"updatedAt": "2023-08-04T00:40:15Z"
}
],
"reviews": []
"reviews": [
{
"id": "PRR_kwDOAUA-v85dGqc0",
"commit": {
"abbreviatedOid": "45eb170"
},
"author": "guoye-zhang",
"authorAssociation": "CONTRIBUTOR",
"state": "APPROVED",
"body": "",
"createdAt": "2023-08-04T00:40:29Z",
"updatedAt": "2023-08-04T00:40:29Z",
"comments": []
}
]
},
{
"number": 2598,
Expand Down Expand Up @@ -154183,6 +154252,48 @@
]
}
]
},
{
"number": 2609,
"id": "PR_kwDOAUA-v85XHICa",
"title": "Replace Upload-Incomplete header with Upload-Complete",
"url": "https://github.com/httpwg/http-extensions/pull/2609",
"state": "MERGED",
"author": "Acconut",
"authorAssociation": "MEMBER",
"assignees": [],
"labels": [],
"body": "Closes https://github.com/httpwg/http-extensions/issues/2500",
"createdAt": "2023-08-03T13:35:23Z",
"updatedAt": "2023-08-04T07:32:39Z",
"baseRepository": "httpwg/http-extensions",
"baseRefName": "main",
"baseRefOid": "42a8669d35143ab5862eb9cf754f72ae88d48224",
"headRepository": "httpwg/http-extensions",
"headRefName": "resumable-upload/upload-complete",
"headRefOid": "487a6bbc343e87de3d2533f3fbcd633d24f93bab",
"closedAt": "2023-08-04T07:32:39Z",
"mergedAt": "2023-08-04T07:32:39Z",
"mergedBy": "Acconut",
"mergeCommit": {
"oid": "1b6a626e27974acf49743f6901bd3611b5ce3235"
},
"comments": [],
"reviews": [
{
"id": "PRR_kwDOAUA-v85dGns_",
"commit": {
"abbreviatedOid": "487a6bb"
},
"author": "guoye-zhang",
"authorAssociation": "CONTRIBUTOR",
"state": "APPROVED",
"body": "",
"createdAt": "2023-08-04T00:20:18Z",
"updatedAt": "2023-08-04T00:20:18Z",
"comments": []
}
]
}
]
}

0 comments on commit a2565ba

Please sign in to comment.