From 137b9b81be6adedf2eba58b27eda6776bd188df8 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Sun, 29 Sep 2024 00:58:47 +0000 Subject: [PATCH] Script updating archive at 2024-09-29T00:58:47Z. [ci skip] --- archive.json | 213 +++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 199 insertions(+), 14 deletions(-) diff --git a/archive.json b/archive.json index 9f2da48d6..19115abce 100644 --- a/archive.json +++ b/archive.json @@ -1,6 +1,6 @@ { "magic": "E!vIA5L86J2I", - "timestamp": "2024-09-24T00:52:28.245728+00:00", + "timestamp": "2024-09-29T00:56:42.509888+00:00", "repo": "httpwg/http-extensions", "labels": [ { @@ -277,6 +277,11 @@ "name": "zstd-window-size", "description": "", "color": "FBCA04" + }, + { + "name": "no-vary-search", + "description": "", + "color": "fbca04" } ], "issues": [ @@ -64031,7 +64036,7 @@ "id": "I_kwDOAUA-v86QnEIk", "title": "SERVICE-WORKERS reference", "url": "https://github.com/httpwg/http-extensions/issues/2843", - "state": "OPEN", + "state": "CLOSED", "author": "mnot", "authorAssociation": "MEMBER", "assignees": [ @@ -64042,8 +64047,8 @@ ], "body": "Is this really normative?\r\n", "createdAt": "2024-07-23T21:26:01Z", - "updatedAt": "2024-08-08T18:58:03Z", - "closedAt": null, + "updatedAt": "2024-09-25T14:02:13Z", + "closedAt": "2024-09-25T14:02:13Z", "comments": [ { "author": "sbingler", @@ -64328,7 +64333,7 @@ ], "body": "Hello. I hope that these comments/questions are helpful. If not, please feel free to ignore them.\r\n\r\nThe QUERY extension says that a server may respond with an Accept-Query header whose value is a list of _one or more_ content types it supports for encoding queries. \r\n\r\n1. How does a server advertise its support for QUERY if it places no restriction on the content type? The grammar for the header value says that at least one content type must be specified. \r\n2. Should we specify (for the sake of explicitness _not_ correctness) how the Accept-Query header interacts/overlaps with Allow? In particular, does a 405 response that includes an Accept-Query header mean that QUERY does not need to appear in Allow?\r\n\r\nAgain, I hope that these questions are helpful. If they are, and there is a consensus on how to proceed, I would be more than happy to help draft some changed language. If these are not helpful, please just tell me to go away.\r\n\r\nThanks for your work on this interesting extension!", "createdAt": "2024-08-07T23:14:29Z", - "updatedAt": "2024-09-17T12:44:37Z", + "updatedAt": "2024-09-25T04:45:50Z", "closedAt": null, "comments": [ { @@ -64386,6 +64391,13 @@ "body": "Suppose you have a resource which allows `PUT` _and_ `QUERY` meaning very different things, such that the sets of accepted request body MIME types for those two methods are disjoint, then `Accept-` might be a reasonable extension in general, and `Accept-Query` a reasonable extension in particular. Perhaps then `Accept-Query` should be generalized to `Accept-`.", "createdAt": "2024-09-17T12:44:36Z", "updatedAt": "2024-09-17T12:44:36Z" + }, + { + "author": "zenomt", + "authorAssociation": "NONE", + "body": "there are already `Accept-Patch` and `Accept-Post` response fields in the [IANA HTTP Field Name Registry](https://www.iana.org/assignments/http-fields/http-fields.xhtml). i think `Accept-Query` is valuable for the same reasons those other `Accept-` ones are, and that its value should be `1#media-type`, both for consistency with `Accept`, `Accept-Patch`, and `Accept-Post`, as well as to allow media-type parameters along with the principal type/subtype.\r\n\r\nthe use case i'm envisioning is advertising support for, say, specialized profiles of a media type, like for example\r\n\r\n```\r\nAccept-Query: application/ld+json; profile=\"http://zenomt.com/ns/jsonld-terse http://example.com/ns/terse-query\"\r\n```\r\n", + "createdAt": "2024-09-25T04:45:49Z", + "updatedAt": "2024-09-25T04:45:49Z" } ] }, @@ -64965,6 +64977,112 @@ "updatedAt": "2024-09-17T12:09:28Z" } ] + }, + { + "number": 2903, + "id": "I_kwDOAUA-v86XzsdY", + "title": "QUERY: add IANA Consideration for Accept-Query", + "url": "https://github.com/httpwg/http-extensions/issues/2903", + "state": "OPEN", + "author": "zenomt", + "authorAssociation": "NONE", + "assignees": [], + "labels": [ + "query-method" + ], + "body": "the IANA Considerations section should request adding the `Accept-Query` header field to the [HTTP Field Name Registry](https://www.iana.org/assignments/http-fields/http-fields.xhtml).", + "createdAt": "2024-09-25T04:51:55Z", + "updatedAt": "2024-09-25T05:13:36Z", + "closedAt": null, + "comments": [] + }, + { + "number": 2904, + "id": "I_kwDOAUA-v86YJzEA", + "title": "Divide and conquer with the existing is a clean alternative to the proposed HTTP QUERY method", + "url": "https://github.com/httpwg/http-extensions/issues/2904", + "state": "OPEN", + "author": "rafageist", + "authorAssociation": "NONE", + "assignees": [], + "labels": [ + "query-method" + ], + "body": "Instead of introducing the QUERY method for complex queries, I propose a divide-and-conquer strategy using existing methods. This allows handling complex payloads without introducing new HTTP methods.\r\n\r\n> [!IMPORTANT]\r\n> Complex queries are intended for sophisticated backend systems capable of processing and storing such requests. Both the proposed QUERY method and my example are meant for advanced scenarios, not simple use cases. So we are talking about the same context, the same problem and different solutions.\r\n\r\nHere is the approach with a hypothetical example:\r\n\r\n> [!WARNING]\r\n> You don't need to make 2 requests for each query, the first time is enough if you get creative. The example sends a query template that dynamically generates a URL for subsequent queries, allowing you to reuse the query results efficiently.\r\n\r\n## Tell the server that you need to make a complex query and receive a response that your query was registered. \r\n\r\nYou can optionally tell it which path you want to consume or return a UUID.\r\n\r\nRequest:\r\n\r\n```http\r\nPOST /query\r\n{\r\n \"desiredUrl\": \"/productos/stock/dell-apple-hp/laptops-500-1500/ratings-4plus-ram-8GB-16GB/{{page}}\",\r\n \"page\": \"{{page}}\"\r\n \"filters\": {\r\n \"category\": \"electronics\",\r\n \"subCategory\": \"laptops\",\r\n \"priceRange\": {\r\n \"min\": 500,\r\n \"max\": 1500\r\n },\r\n \"availability\": \"in_stock\",\r\n \"brands\": [\"Dell\", \"Apple\", \"HP\"],\r\n \"sort\": {\r\n \"field\": \"ratings\",\r\n \"order\": \"desc\"\r\n },\r\n \"attributes\": {\r\n \"screenSize\": [\"13-inch\", \"15-inch\"],\r\n \"processorType\": [\"Intel\", \"AMD\"],\r\n \"ram\": [\"8GB\", \"16GB\"]\r\n }\r\n }\r\n}\r\n```\r\n\r\nResponse:\r\n```http\r\nContent-type: application/json\r\n\r\n{\r\n \"query_uuid\": \"89fbf974-4565-4bf6-8e9e-e1fd8585a0dc\"\r\n}\r\n```\r\n\r\n## Ask the server about the results of your request\r\n\r\nRequest:\r\n```http\r\nGET /productos/stock/dell-apple-hp/laptops-500-1500/ratings-4plus-ram-8GB-16GB/1\r\n```\r\n\r\nResponse:\r\n\r\n```http\r\nContent-type: application/json\r\n\r\n{\r\n \"totalPages\": 100,\r\n \"page\": 1,\r\n \"products\": [\r\n {\r\n \"id\": 101,\r\n \"name\": \"Dell XPS 13\",\r\n \"category\": \"laptops\",\r\n \"price\": 1200,\r\n \"availability\": \"in_stock\",\r\n \"brand\": \"Dell\",\r\n \"rating\": 4.5,\r\n \"attributes\": {\r\n \"screenSize\": \"13-inch\",\r\n \"processorType\": \"Intel Core i7\",\r\n \"ram\": \"16GB\",\r\n \"storage\": \"512GB SSD\"\r\n }\r\n },\r\n {\r\n \"id\": 102,\r\n \"name\": \"Apple MacBook Air\",\r\n \"category\": \"laptops\",\r\n \"price\": 1500,\r\n \"availability\": \"in_stock\",\r\n \"brand\": \"Apple\",\r\n \"rating\": 4.7,\r\n \"attributes\": {\r\n \"screenSize\": \"13-inch\",\r\n \"processorType\": \"M1\",\r\n \"ram\": \"16GB\",\r\n \"storage\": \"512GB SSD\"\r\n }\r\n },\r\n {\r\n \"id\": 103,\r\n \"name\": \"HP Spectre x360\",\r\n \"category\": \"laptops\",\r\n \"price\": 1400,\r\n \"availability\": \"in_stock\",\r\n \"brand\": \"HP\",\r\n \"rating\": 4.3,\r\n \"attributes\": {\r\n \"screenSize\": \"15-inch\",\r\n \"processorType\": \"Intel Core i5\",\r\n \"ram\": \"8GB\",\r\n \"storage\": \"256GB SSD\"\r\n }\r\n }\r\n ]\r\n}\r\n```\r\n\r\nI hope these examples have clarified how complex queries can be effectively handled using existing methods. This method offers flexibility to handle sophisticated queries on advanced backends, requests that can be pre-processed, optimized, cached, return an early error, reused, etc.\r\n\r\nI welcome any comments and feedback from the community. Thank you for considering my idea and I hope it has contributed to the ongoing discussion.", + "createdAt": "2024-09-27T11:35:53Z", + "updatedAt": "2024-09-28T15:45:56Z", + "closedAt": null, + "comments": [ + { + "author": "reschke", + "authorAssociation": "CONTRIBUTOR", + "body": "From a quick glace, this misses the point of QUERY - having a method that can pass data in the request body which is \"safe\".\r\n\r\nIf \"safeness\" of the request is irrelevant, then yes, you can POST.", + "createdAt": "2024-09-28T15:45:55Z", + "updatedAt": "2024-09-28T15:45:55Z" + } + ] + }, + { + "number": 2906, + "id": "I_kwDOAUA-v86YMLKU", + "title": "No-Vary-Search: Add an introduction", + "url": "https://github.com/httpwg/http-extensions/issues/2906", + "state": "OPEN", + "author": "jeremyroman", + "authorAssociation": "CONTRIBUTOR", + "assignees": [], + "labels": [ + "no-vary-search" + ], + "body": "Migrated from https://github.com/jeremyroman/http-no-vary-search/issues/5\r\n\r\n> The draft doesn't bother with any of the usual frippery that is in other similar documents, like establishing what the problem is, why it is important to solve, and providing an overview of the solution. That's going to be challenging.", + "createdAt": "2024-09-27T16:35:36Z", + "updatedAt": "2024-09-27T16:35:36Z", + "closedAt": null, + "comments": [] + }, + { + "number": 2907, + "id": "I_kwDOAUA-v86YMLor", + "title": "No-Vary-Search: WHATWG list notation \u00ab \u00bb is unfamiliar to some readers", + "url": "https://github.com/httpwg/http-extensions/issues/2907", + "state": "OPEN", + "author": "jeremyroman", + "authorAssociation": "CONTRIBUTOR", + "assignees": [], + "labels": [ + "no-vary-search" + ], + "body": "Migrated from https://github.com/jeremyroman/http-no-vary-search/issues/4", + "createdAt": "2024-09-27T16:36:51Z", + "updatedAt": "2024-09-27T19:42:13Z", + "closedAt": null, + "comments": [ + { + "author": "domenic", + "authorAssociation": "NONE", + "body": "I noticed it used in https://johannhof.github.io/draft-annevk-johannhof-httpbis-cookies/draft-annevk-johannhof-httpbis-cookies.html", + "createdAt": "2024-09-27T19:42:12Z", + "updatedAt": "2024-09-27T19:42:12Z" + } + ] + }, + { + "number": 2908, + "id": "I_kwDOAUA-v86YMOEm", + "title": "No-Vary-Search: Handling multiple matches and efficient cache implementation", + "url": "https://github.com/httpwg/http-extensions/issues/2908", + "state": "OPEN", + "author": "jeremyroman", + "authorAssociation": "CONTRIBUTOR", + "assignees": [], + "labels": [ + "no-vary-search" + ], + "body": "Migrated from https://github.com/WICG/nav-speculation/issues/210.\r\n\r\nThe most active discussion is at the bottom of that issue -- permitting cache implementations to assume a single non-empty `No-Vary-Search` field value per path in order to allow simpler & more efficient implementations, and missing if this isn't the case.", + "createdAt": "2024-09-27T16:43:22Z", + "updatedAt": "2024-09-27T16:43:23Z", + "closedAt": null, + "comments": [] } ], "pulls": [ @@ -164358,7 +164476,7 @@ "abbreviatedOid": "9b9edb7" }, "author": "jeremyroman", - "authorAssociation": "NONE", + "authorAssociation": "CONTRIBUTOR", "state": "COMMENTED", "body": "a couple nitpicks while passing by", "createdAt": "2023-12-08T20:27:36Z", @@ -172330,7 +172448,7 @@ "id": "PR_kwDOAUA-v85335ZS", "title": "Make Service-Workers reference informative", "url": "https://github.com/httpwg/http-extensions/pull/2861", - "state": "OPEN", + "state": "MERGED", "author": "sbingler", "authorAssociation": "COLLABORATOR", "assignees": [], @@ -172339,17 +172457,19 @@ ], "body": "Closes #2843 ", "createdAt": "2024-08-08T19:13:37Z", - "updatedAt": "2024-09-18T13:56:47Z", + "updatedAt": "2024-09-25T14:02:12Z", "baseRepository": "httpwg/http-extensions", "baseRefName": "main", "baseRefOid": "8dec5fc1cdc45adbb33238dddf63382b38d158bd", "headRepository": "sbingler/http-extensions", "headRefName": "UpdateServiceWorkerRef", - "headRefOid": "9e5533abc90323aee80bb58f0343de9d0c42b1bb", - "closedAt": null, - "mergedAt": null, - "mergedBy": null, - "mergeCommit": null, + "headRefOid": "1e0cc4ba2cba604b4152249febaa23992392ad97", + "closedAt": "2024-09-25T14:02:12Z", + "mergedAt": "2024-09-25T14:02:12Z", + "mergedBy": "sbingler", + "mergeCommit": { + "oid": "4a695bbf19b21805cb5a45226e9882121475488e" + }, "comments": [ { "author": "sbingler", @@ -172359,7 +172479,34 @@ "updatedAt": "2024-09-18T13:56:44Z" } ], - "reviews": [] + "reviews": [ + { + "id": "PRR_kwDOAUA-v86KxlIi", + "commit": { + "abbreviatedOid": "9e5533a" + }, + "author": "mikewest", + "authorAssociation": "MEMBER", + "state": "APPROVED", + "body": "LGTM % nits.", + "createdAt": "2024-09-25T13:23:57Z", + "updatedAt": "2024-09-25T13:25:27Z", + "comments": [ + { + "originalPosition": 25, + "body": "```suggestion\r\n target: https://www.w3.org/TR/service-workers/\r\n```", + "createdAt": "2024-09-25T13:23:57Z", + "updatedAt": "2024-09-25T13:25:27Z" + }, + { + "originalPosition": 36, + "body": "```suggestion\r\n -\r\n ins: J. Archibald\r\n name: Jake Archibald\r\n -\r\n ins: M. Kruisselbrink\r\n name: Marijn Kruisselbrink\r\n```", + "createdAt": "2024-09-25T13:25:11Z", + "updatedAt": "2024-09-25T13:25:27Z" + } + ] + } + ] }, { "number": 2862, @@ -173181,6 +173328,44 @@ "comments": [] } ] + }, + { + "number": 2905, + "id": "PR_kwDOAUA-v8588RWP", + "title": "Add draft-ietf-httpbis-no-vary-search", + "url": "https://github.com/httpwg/http-extensions/pull/2905", + "state": "MERGED", + "author": "jeremyroman", + "authorAssociation": "CONTRIBUTOR", + "assignees": [], + "labels": [ + "no-vary-search" + ], + "body": "This has been adopted by the working group as of Sept 25, 2024, after previously existing at:\r\n https://github.com/jeremyroman/http-no-vary-search\r\n https://github.com/WICG/nav-speculation", + "createdAt": "2024-09-27T16:12:22Z", + "updatedAt": "2024-09-27T16:20:17Z", + "baseRepository": "httpwg/http-extensions", + "baseRefName": "main", + "baseRefOid": "4a695bbf19b21805cb5a45226e9882121475488e", + "headRepository": "jeremyroman/http-extensions", + "headRefName": "no-vary-search-initial", + "headRefOid": "d2a96d9e8eb5b30ef522e56c189a6f4ddd87aed3", + "closedAt": "2024-09-27T16:19:50Z", + "mergedAt": "2024-09-27T16:19:50Z", + "mergedBy": "tfpauly", + "mergeCommit": { + "oid": "126d2140c53ff25dc1616e4c1d3cb1ff91c09e8d" + }, + "comments": [ + { + "author": "jeremyroman", + "authorAssociation": "CONTRIBUTOR", + "body": "@mnot @tfpauly PTAL?", + "createdAt": "2024-09-27T16:13:34Z", + "updatedAt": "2024-09-27T16:13:34Z" + } + ], + "reviews": [] } ] } \ No newline at end of file