Skip to content

Commit

Permalink
Script updating archive at 2024-10-01T01:02:34Z. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed Oct 1, 2024
1 parent 137b9b8 commit a29dda0
Showing 1 changed file with 74 additions and 6 deletions.
80 changes: 74 additions & 6 deletions archive.json
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"magic": "E!vIA5L86J2I",
"timestamp": "2024-09-29T00:56:42.509888+00:00",
"timestamp": "2024-10-01T01:00:19.179400+00:00",
"repo": "httpwg/http-extensions",
"labels": [
{
Expand Down Expand Up @@ -61346,7 +61346,7 @@
],
"body": "The draft currently defines the \"target_host\" and \"tcp_port\" variables. We should replace \"tcp_port\" with \"target_port\" for consistency with connect-udp. This consistency isn't just cosmetic, it simplifies reusing the same URI template for both protocols.",
"createdAt": "2024-01-25T00:46:11Z",
"updatedAt": "2024-07-22T22:12:29Z",
"updatedAt": "2024-09-30T12:30:49Z",
"closedAt": "2024-07-22T22:12:29Z",
"comments": [
{
Expand Down Expand Up @@ -64710,7 +64710,7 @@
],
"body": "See discussion in [HN thread](https://news.ycombinator.com/item?id=41552804).",
"createdAt": "2024-09-16T21:37:24Z",
"updatedAt": "2024-09-18T10:21:39Z",
"updatedAt": "2024-09-30T20:21:01Z",
"closedAt": null,
"comments": [
{
Expand Down Expand Up @@ -64747,6 +64747,27 @@
"body": "Yes, the _server_ can normalize however it wants and it's a local detail for it. But caches need not be located in the server, and _caches_ may not be able to normalize the same way as the _servers_.",
"createdAt": "2024-09-18T10:21:37Z",
"updatedAt": "2024-09-18T10:21:37Z"
},
{
"author": "rafageist",
"authorAssociation": "NONE",
"body": "I\u2019d like to expand on the semantic nature of QUERY. Given the name, it implies querying an endpoint, but how do we semantically define what constitutes a \"query\"? Without clear guidelines, there\u2019s potential for abuse, as QUERY could be used for anything. \r\n\r\nUnlike GET, POST, PUT, or PATCH, which are generic, QUERY sounds specific, but the ambiguity opens the door to misuse. Additionally, with many possible query languages (e.g., SQL, GraphQL), if the protocol doesn\u2019t define this, as it does with URIs (which have a well-defined query syntax), maybe QUERY isn\u2019t the best name. Maybe: FETCH, RETRIEVE, REQUEST\r\n\r\nAnd although I don't like the idea of \u200b\u200bdoing a GET with body, the body could be very strict like the query params of a URL.",
"createdAt": "2024-09-30T00:19:54Z",
"updatedAt": "2024-09-30T00:22:05Z"
},
{
"author": "reschke",
"authorAssociation": "CONTRIBUTOR",
"body": "It *is* generic. It's safe method that can, contrary to GET, use a body.\r\n\r\nWhat kind of \"abuse\" do you fear? If it's about not using URIs for stuff that *could* have a URI, that would indeed be sup-optimal, and we can add a reminder that this is not the point of QUERY. Ultimately, it's up to the people building stuff on top of HTTP.\r\n\r\nSpecific semantics will be defined based on media types of the request body.",
"createdAt": "2024-09-30T05:50:43Z",
"updatedAt": "2024-09-30T05:53:49Z"
},
{
"author": "rafageist",
"authorAssociation": "NONE",
"body": "If the body content behaves similarly to a POST, a more neutral name might be more fitting, as it wouldn't limit its usage to strict queries. This would help avoid confusion about its actual purpose and align the functionality with the name. In this case, QUERY (formerly known as SEARCH) wouldn't be an enhanced GET, but rather an **idempotent POST**.\r\n",
"createdAt": "2024-09-30T20:20:59Z",
"updatedAt": "2024-09-30T20:20:59Z"
}
]
},
Expand Down Expand Up @@ -65001,7 +65022,7 @@
"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",
"state": "CLOSED",
"author": "rafageist",
"authorAssociation": "NONE",
"assignees": [],
Expand All @@ -65010,15 +65031,43 @@
],
"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,
"updatedAt": "2024-09-30T00:28:32Z",
"closedAt": "2024-09-29T15:19:44Z",
"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"
},
{
"author": "rafageist",
"authorAssociation": "NONE",
"body": "@reschke Thanks for the feedback! I understand the idea of \"safe\" in QUERY, as in GET. However, I think complex queries in the body of a request could be a symptom of poor design. HTTP methods are designed for simple, modular tasks, allowing them to be combined to solve complex problems. Creating a new method like QUERY introduces unnecessary complexity and can dilute the clarity of current methods.\r\n\r\nIf approved, we could see bad practices and overloading servers with queries that should be optimized in the architecture. It could also open the door to hundreds of new methods, turning the protocol into a full application layer. This risks breaking the balance and simplicity that HTTP was built on.\r\n\r\nExisting HTTP methods confirm to the Unix principle of **doing one thing well**, while QUERY risks breaking that principle by being too flexible.",
"createdAt": "2024-09-29T01:23:00Z",
"updatedAt": "2024-09-29T01:23:11Z"
},
{
"author": "rafageist",
"authorAssociation": "NONE",
"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\n> If \"safeness\" of the request is irrelevant, then yes, you can POST.\r\n\r\n@reschke Re-reading your comment made me realize something important.\r\n\r\nThe \"point of\" QUERY cannot simply be the creation of the method itself. There must be a stronger, more meaningful reason behind its existence, something that provides unique value that cannot be achieved with current HTTP methods or through architectural improvements. Creating a new method just because you want to combine features of GET and POST is not a sufficient reason. The purpose of QUERY should clearly answer why it is needed and what its real value is.\r\n\r\nWhen designing something in software engineering, or any other technology, we typically ask ourselves three questions: \r\n\r\n- What are we trying to achieve? \r\n- How should it be implemented? \r\n- Why do we need it? \r\n\r\nIn this case, while QUERY answers the \u201cwhat\u201d and the \u201chow,\u201d I think the \u201cwhy\u201d is still unclear. What real benefit does QUERY provide that can\u2019t be solved by better architecture or existing methods like POST or GET?\r\n\r\nIf the purpose of QUERY is to allow more complex queries by sending a body in the request (it is possible now, but not official), a simpler solution would be to simply allow bodies in GET within the HTTP specification, rather than introducing a new method. This would keep the semantics clear, avoiding the need to create a new method that could cause confusion and bad practices. In the end, the question is whether we really need a new method or whether we can adjust the existing rules to achieve the same goal.\r\n\r\nNow ask yourself why no body has been specified for the GET?\r\n\r\nThe designers of the HTTP protocol originally decided not to allow bodies in GET because its purpose is to request resources without altering the state of the server, and bodies were considered unnecessary for that. By keeping GET bodyless, the simplicity and clarity of the protocol is preserved, avoiding complications with caching semantics and idempotence. However, it is unclear whether, in the current context, this decision could be revisited, as allowing bodies in GET could solve many problems.",
"createdAt": "2024-09-29T10:39:21Z",
"updatedAt": "2024-09-30T00:28:32Z"
},
{
"author": "reschke",
"authorAssociation": "CONTRIBUTOR",
"body": "That topic has been discussed multiple times in the past, and the result always was: don't. See https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.1-6.\r\n\r\nAs stated earlier, that's the reason why QUERY is being defined.",
"createdAt": "2024-09-29T15:19:44Z",
"updatedAt": "2024-09-29T15:19:44Z"
},
{
"author": "rafageist",
"authorAssociation": "NONE",
"body": "> That topic has been discussed multiple times in the past, and the result always was: don't. See https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.1-6.\r\n> \r\n> As stated earlier, that's the reason why QUERY is being defined.\r\n\r\n@reschke The HTTP protocol (RFC 9110) specifies that the GET method refers to a URI, and the URI specification (RFC 3986) does not impose a size limit on these identifiers. Therefore, any limitation on the length of parameters in the URL **is not a deficiency of the protocol**, but of the intermediate implementations (browsers, servers, proxies). Rather than changing the protocol with methods like QUERY, it would be more logical to optimize the ecosystem to handle longer query parameters or implement better solutions as this issue proposes.\r\n\r\n>[!IMPORTANT]\r\n>The HTTP QUERY proposal attempts to solve a problem in the protocol that is not part of the protocol, when it is an ecosystem problem and must be solved in the ecosystem.\r\n\r\nTherefore, the topic you reference reinforces my point even more. The reason for not allowing a body in GET is well-established, and creating a method like QUERY seems forced. **You\u2019ve dismissed the rest of the arguments, focusing only on the lack of a body in GET**, but haven't provided a solid reason why QUERY is needed and **the proposal is vague in its rationale**. \r\n\r\nThe only justification seems to be the risk of URL truncation, which is not a deficiency of the HTTP protocol itself, but of the points along the request path and the ingenuity of developers in structuring URLs and optimizing the systems they implement.\r\n\r\nThe HTTP QUERY proposal brings more problems than solutions to this world: \r\n\r\n- network overload\r\n- performance degradation\r\n- security vulnerabilities\r\n- unnecessary complexity\r\n- redundancy\r\n- cache inefficiencies\r\n- breaking HTTP semantics\r\n- misuse and bad practices\r\n- lack of backward compatibility\r\n- implementation challenges\r\n\r\nAn article will be written and published recommending the solution given in this issue and the concerns regarding the HTTP QUERY proposal. All those possible problems will be detailed.\r\n\r\nThanks for your time.",
"createdAt": "2024-09-29T20:29:21Z",
"updatedAt": "2024-09-29T20:29:21Z"
}
]
},
Expand Down Expand Up @@ -65083,6 +65132,25 @@
"updatedAt": "2024-09-27T16:43:23Z",
"closedAt": null,
"comments": []
},
{
"number": 2909,
"id": "I_kwDOAUA-v86YVBNc",
"title": "query: potentially add text discussing relation to 'Building Protocols with HTTP' ",
"url": "https://github.com/httpwg/http-extensions/issues/2909",
"state": "OPEN",
"author": "reschke",
"authorAssociation": "CONTRIBUTOR",
"assignees": [],
"labels": [
"editorial",
"query-method"
],
"body": "Specifically: https://www.rfc-editor.org/rfc/rfc9205.html#using-http-methods",
"createdAt": "2024-09-30T06:05:11Z",
"updatedAt": "2024-09-30T06:05:22Z",
"closedAt": null,
"comments": []
}
],
"pulls": [
Expand Down

0 comments on commit a29dda0

Please sign in to comment.