HTTP Working Group Minutes - IETF 121

Monday, 4 November 2024

09:30 - 11:30 Monday Session I - Wicklow Hall 1

Active Drafts

Resumable Uploads

Marius Kleidl

QUERY Method

Mike Bishop

#2896 Normalization

Cache Groups

Mark Nottingham

Other Topics

Incremental HTTP Messages

Kazuho Oku

The HTTP Wrap Up Capsule

Lucas Pardue

(Not the last presentation)

Guidance for HTTP Capsule Protocol Extensibility

Lucas Pardue

Yoav Weiss remote

Thursday, 7 November 2024

17:30 - 18:30 Thursday Session IV - Liffey Hall 2

Meetecho - full client / onsite

AD-Requested Feedback

Active Drafts

Template-Driven CONNECT for TCP

Ben Schwartz remote (slides)

David Schinazi: We already live in a world where we already need more than a URI. You need a separate part of your config, such as how to configure a proxy. We already have a solution for. Recommendation: whatever mechanism you use to configure your client with a proxy should include the upgrade tokens. We should have 2 upgrade tokens, and clients or servers can choose what they implement. No "MUST implement"

Kazuho Oku: Mostly agree with David. We have 3 options including "legacy CONNECT" Wondering if people are interested in implementing 'connect-tcp'

Tommy Pauly: Agree its vague what connect-tcp means. Recommend it's always the capsule. Puts it on par with other token based protocols. If you want no capsule, just use legacy CONNECT. This removes one of the variables

Lucas Pardue: Dont like that the server says you have to do 2 things. Want to chose whatever to do. Propose use a different protocol thing as a compromise. As a server provider, don't want to have to support both.

Mike Bishop: Shares previous opinions. If we know we need capsules, then lets just have capsules. Lets go all the way and use capsules.

Mirja Kühlewind: In this design you already have 2 things (protocol and capsule-protocol fields). If you take

Ben: That's from the capsule protocol, outside of this draft.

David Schinazi: "that's fair" emoji. Strongly agree with ben here, but that wasn't the consensus of masque wg group at the time. Since it was optional, we can't depend on it.

Mark: Seems like we need more discussion.

Ben: mostly likely way forward is to consolidate on a single protocol.

Mark: I see thumbs up in the room.

Security Considerations for Optimistic Use of HTTP Upgrade

Ben Schwartz remote (slides)

Ben: Feedback? I'm not aware of other necessary changes.

Eric Kinnear: comment on closing the connection. better if we have to do something else from security POV

Ben: clarify? is this about 407?

Eric: I'm going to reject your connect and also close everything. Proxy authentication is degraded by this. An actual HTTP connect proxy. Implementation impairment. Many failure mode variants, difficult for client to understand what is really happening.

Ben: Interesting to hear this.

Eric: We see this problems for other proxy flows as well. Good to avoid this here.

Ben: How about a request header to signal a well behaving client? (laughing audience)

Tommy Pauly: Notable new text requires some nit. This doc is focused on advice for http/1.1. We should be specific that this is HTTP/1.1 focused.

Mark: if you are placing RFC2119 requirements, do you also need to update RFC9110

Ben: interesting question! Not sure where we go from here. Eric, if you have suggestions on changes to this section, that would be great.

Mark: feels like we're getting close to last-call, folks should review.

Jeremy Roman

Mark Nottingham: The efficiency mechanism reminds me of the key header. Cache implementers (non-browsers) need to think about this and bring anything back to the group. This is in-band now. Need time for them to digest that.

Valentin Goșu: Thank you for working on this. +1 on considerations for efficient implementations. If web sites and browser implementers don't agree this won't help improve cache hit rate. Thankful it is not a regex. I think this is good.

Darrel Miller: feedback from non-browser user on naming: "search" is odd. what about another word?

Jeremy: We had other name "no-vary" at the beginning and got feedback that "search" is ok.

Mark: In this area, terminology is inconsistent across across the ecosystem. When talking about naming, defer to editors. AI generated pictures of bikesheds is unhelpful. :)

Mark: making good progress here

Phillip Hallam-Baker: "search" is a relic from the past

Other Topics

The IP Geolocation HTTP Client Hint

Ciara McMullin

Ted Hardie: appreciates the privacy focus. There has been previous work on GEOPRIV with no implementations. idea is that in addition to having the location, you have somebody who cares about the revelation of their location the idea of a maker is kind of central to that.
Once you create a header like this, there is no guarantee that people will use it. Since many VPNs are designed to hide location, this could compromise that.

Other approach: geo feed from client. reduces number of IP addresses in IP pool, which is good.

Suspect there are others things that will be surfaced as we move forward. Rather than adopt this, adopt a requirements process for how we do geolocation using HTTP while maintaining privacy.

Mark: This is the beginning of a conversation to determine if we want to talk about this more.

Stephen Farrel: First, user intended, confusion of those kinds of phrases will make the conversation harder. Second, I agree with Ted. going through use cases and requirements is helpful before we do anything. Maybe doing nothing is the right idea.

Kyle Nekritz: Clarify intent? reduce size of IP pool?

Ciara: mask client IP with proxy, but pool size is not priority

Tommy: goal is to slowly wean the ecosystem off IP based geolocation.

Philip Hallam Baker: I am happy to control this as a user. Setting my preferred location is good. That header will be abused by users to see stuff they shouldn't

Yaroslv Rosomakho: There is another significant challenge which is the question of trust between proxy and destination service. Very few destinations trust headers that proxies use to expose origin IP. We should discuss how intermediaries can sign those headers so that origin servers can trust it.

Eric Kinnear: are we in place to have separate signals for IP address and location? Today we have both. Can we make them separate?

Piotr Sikora: as a server I cannot trust this. with MASQUE can this leak the IP address?how does this work with MASQUE?

Ben Schwartz: The elephant in the room is ma proxy server operators that will customize your location header for a free. Proxy operators come to IETF to bypass the geolocation database providers.

Lucas Pardue: difficult to solve, but this is good to solve

Eric Nygren: This is an important topic. Its not just the cost of the geo providers. IPv4 addresses is small. Privacy proxies to convey this In some cases trust is not necessary such as weather. In other cases like content providers, trust is required.

Shivan Sahib: we were forced to ship client intents. We don't want to be forced again

Scott Hendrickson: We intentionally do not address the problem of trust in this draft. Most proxies do not allow to change location today. We should not address geo hopping here.

Mark: Interest in the room discussing this further. Further discussion in the future. No decision yet.