- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 5 Apr 2025 14:47:18 +0200
- To: calsify@ietf.org
- Cc: ietf-http-wg@w3.org
Am 01.04.2025 um 00:36 schrieb The IESG: > ... Hi there, I noticed this draft as the preference IANA registrations were sent to me (as designated expert). Those seem to be related to "Enhanced GET" (<https://www.ietf.org/archive/id/draft-ietf-calext-subscription-upgrade-13.html#name-enhanced-get>). From an HTTP point of view I'll say: don't. Looking at <https://www.ietf.org/archive/id/draft-ietf-calext-subscription-upgrade-13.html#name-examples>: > EXAMPLE 1 > > This is an example of the initial request and response from a server that supports the enhanced GET method. Note the use of the Vary header so a caching proxy can key off the client's Sync-Token and preference. > > >> Request << > > GET /events.ics HTTP/1.1 > Host: example.com > Accept: text/calendar > Prefer: subscribe-enhanced-get > > >> Response << > > HTTP/1.1 200 OK > Content-Length: xxxx > Sync-Token: "data:,1234567" Replace "Sync-Token" by "Etag". > Preference-Applied: subscribe-enhanced-get > Vary: Prefer, Sync-Token Drop both. > BEGIN:VCALENDAR: > ? /* full feed */ > END:VCALENDAR > > EXAMPLE 2 > > This is an example of the subsequent request and response when no changes have occurred. > > >> Request << > > GET /events.ics HTTP/1.1 > Host: example.com > Accept: text/calendar > Prefer: subscribe-enhanced-get Drop this. > Sync-Token: "data:,1234567" Make this: If-None-Match: "data:,1234567" > >> Response << > > HTTP/1.1 304 Not Modified > Content-Length: 0 > Sync-Token: "data:,1234567" Replace "Sync-Token" by "Etag". > Preference-Applied: subscribe-enhanced-get > Vary: Prefer, Sync-Token Drop both. > EXAMPLE 3 > > This is an example of the subsequent request and response for an old or invalid token. > >>> Request << > > GET /events.ics HTTP/1.1 > Host: example.com > Accept: text/calendar > Sync-Token: "data:,1234567" Make this: If-Match: "data:,1234567" > Prefer: subscribe-enhanced-get Drop this. > >> Response << > > HTTP/1.1 409 Conflict > Content-Length: xxxx > Preference-Applied: subscribe-enhanced-get That would be a 412 (Precondition Failed). > EXAMPLE 4 > > This is an example of the subsequent request and response when changes have occurred. > >>> Request << > > GET /events.ics HTTP/1.1 > Host: example.com > Accept: text/calendar > Sync-Token: "data:,1234567" Make this: If-None-Match: "data:,1234567" > Prefer: subscribe-enhanced-get Drop this. > >> Response << > > HTTP/1.1 200 OK > Content-Type: text/calendar > Vary: Prefer, Sync-Token Vary: If-None-Match > Sync-Token: "data:,4567890" ...new Etag. > Preference-Applied: subscribe-enhanced-get > BEGIN:VCALENDAR: > ... only new/changed events > ... deleted events have STATUS:DELETED > END:VCALENDAR I believe with that, you don't need "Enhanced GET" at all, and thus likely no new preference values. Best regards, Julian
Received on Saturday, 5 April 2025 12:47:24 UTC