Script updating archive at 2024-01-04T00:42:38Z. [ci skip]

httpwg · Jan 4, 2024 · fe5fde4 · fe5fde4
1 parent a3a63e0
commit fe5fde4
Showing 1 changed file with 31 additions and 3 deletions.
diff --git a/archive.json b/archive.json
@@ -1,6 +1,6 @@
 {
   "magic": "E!vIA5L86J2I",
-  "timestamp": "2023-12-24T00:42:44.657621+00:00",
+  "timestamp": "2024-01-04T00:40:23.455101+00:00",
   "repo": "httpwg/http-extensions",
   "labels": [
     {
@@ -52253,7 +52253,7 @@
       ],
       "body": "IIUC, with #2292, we have two resources. One being the resource to which the transaction is started (A), and another to which the chunks are sent (B).\r\n\r\nAssuming that responses that we get for resource B is that for resource B, how do we obtain the response for resource A when the upload is complete?\r\n\r\nTo give an example, consider the following case:\r\n* Client starts a POST to /foo, and server sends a 1xx response specifying a transaction resource /transaction/1234.\r\n* The clients uploads the final chunk to /transaction/1234, and gets a 500 response.\r\n\r\nDoes this 500 mean that the upload of the final chunk failed? Or is it a response for the original request (for resource A)?",
       "createdAt": "2022-11-11T10:29:11Z",
-      "updatedAt": "2023-11-24T11:46:59Z",
+      "updatedAt": "2023-12-28T15:44:46Z",
       "closedAt": null,
       "comments": [
         {
@@ -52325,6 +52325,13 @@
           "body": "I agree with the feedback from Prague that Content-Location would be a great fit to solve this problem. The server can sends a URL using Content-Location during the upload. The client can then use this URL to query a potential result of the upload process. I will open a PR to add a note explaining this possibility.",
           "createdAt": "2023-11-24T11:46:58Z",
           "updatedAt": "2023-11-24T11:46:58Z"
+        },
+        {
+          "author": "smatsson",
+          "authorAssociation": "NONE",
+          "body": "I have updated the [tusdotnet POC](https://github.com/tusdotnet/tusdotnet/tree/POC/tus2) to add support for Content-Location. For now it will call [user code](https://github.com/tusdotnet/tusdotnet/blob/POC/tus2/Source/TestSites/AspNetCore_netcoreapp3.1_TestApp/MyTusHandler.cs#L73) each time the Content-Location is requested and the user code can determine if it wants to provide a CL or just ignore the call (resulting in no header returned to the client). \r\n\r\nSome thoughts on Content-Location that are probably not really thought through:\r\n\r\n* Can it change once set? Can it differ between HEAD/POST/PATCH responses? \r\n* Can the header be returned directly when the upload is created or can it only be returned once the upload is complete?\r\n* The URI pointed to by Content-Location - is it allowed to return different data during processing? Based on the below section I would say yes.\r\n> \"Otherwise, such a Content-Location indicates that this payload is\r\n>       a representation reporting on the requested action's status and\r\n>       that the same report is available (for future access with GET) at\r\n>       the given URI.  For example, a purchase transaction made via a\r\n>       POST request might include a receipt document as the payload of\r\n>       the 200 (OK) response; the Content-Location field-value provides\r\n>       an identifier for retrieving a copy of that same receipt in the\r\n>       future.\" - https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.4.2",
+          "createdAt": "2023-12-28T15:44:45Z",
+          "updatedAt": "2023-12-28T15:44:45Z"
         }
       ]
     },
@@ -60047,7 +60054,7 @@
       ],
       "body": "Why does the dictionary lifetime need to be independent of the cache lifetime?  Having an object that is cached with a separate lifetime seems unnecessary.\r\n\r\nI would have said that clients can cache a dictionary for as long as they want (as always), but no longer than the lifetime stated in the cache-control field.\r\n\r\nNow, you might say that a server might want a resource to be usable in its own right (i.e., as an ordinary resource) for one duration, with a separate lifetime for its use as a dictionary.  I see two reasons that this isn't much of a compelling argument:\r\n\r\n* A server can forget about a dictionary and not provide delta compression at any time, so there is no real need for the dictionary lifetime to be shorter than the cache lifetime.   Client caches won't want to retain something for longer than its validity, so I don't see much chance that a resource will be kept past its cache lifetime.\r\n\r\n* Resources like this are likely exclusively used as a dictionary.  There isn't much value for those resources having a separate lifetime in that case.",
       "createdAt": "2023-10-12T23:14:12Z",
-      "updatedAt": "2023-12-19T17:00:37Z",
+      "updatedAt": "2024-01-03T17:16:10Z",
       "closedAt": null,
       "comments": [
         {
@@ -60077,6 +60084,27 @@
           "body": "@LPardue @vkrasnov does using the resource max-age + stale-while-revalidate as and expiration for the client-side dictionary work ok for you (with a recommendation that immutable resources specify expirations based on their typical release cycle)?",
           "createdAt": "2023-12-19T17:00:35Z",
           "updatedAt": "2023-12-19T17:00:35Z"
+        },
+        {
+          "author": "vkrasnov",
+          "authorAssociation": "NONE",
+          "body": "I think that having an explicit life time for the dictionary is a little bit more flexible than relying on cache-control headers, but I think that `max-age` by itself should outlive most dictionary uses I can think of, especially given that the CDN is unlikely to keep those resources in its own cache beyond that period as well.",
+          "createdAt": "2024-01-03T14:49:54Z",
+          "updatedAt": "2024-01-03T14:49:54Z"
+        },
+        {
+          "author": "pmeenan",
+          "authorAssociation": "CONTRIBUTOR",
+          "body": "@vkrasnov I'm not sure I understand (or we're not talking about the same part of the issue).\r\n\r\nThe main concern for caches is how long clients consider a dictionary valid for which will dictate how long of a window a given resource will see `Available-Dictionary:` request headers from.\r\n\r\ne.g. for a dictionary with a max-age of 1 year, clients will advertise that dictionary as being available for up to a year. If there are 1,000 updates to the resource used as a dictionary (not impossible for a js app that has 3 releases per day) then there will be 1,000 variants of the dictionary in the wild at any given time (with more frequent requests for more recent dictionaries but still some infrequent long-tail requests).\r\n\r\nTo prevent cache misses, it would be beneficial to cap the dictionary validity to a smaller window where most return traffic falls in and have older clients download the full resource from cache rather than missing and going back to the origin. It also caps how many delta-compressed versions need to be created.\r\n\r\nThe discussion point is if that \"client valid\" time for a dictionary should be its own separate value or if sites should adjust their max-age to be more reasonable instead if they want to limit the variants (capping the validity to the max-age but requiring a shorter max-age rather than blindly setting everything to 1-year).",
+          "createdAt": "2024-01-03T15:45:42Z",
+          "updatedAt": "2024-01-03T15:45:42Z"
+        },
+        {
+          "author": "pmeenan",
+          "authorAssociation": "CONTRIBUTOR",
+          "body": "Worst-case, a separate ttl could be added later if using the resource expiration ends up being a problem blocking adoption.",
+          "createdAt": "2024-01-03T17:16:10Z",
+          "updatedAt": "2024-01-03T17:16:10Z"
         }
       ]
     },