Also what’s the semantic here when both http:// and https:// URLs map to the same cached object ? The first cached request specifies the scheme? This seems confusing at best... or are we talking about the scheme as it goes to origin (which would have to be the same for both).
Seems like a remap plugin could just look at the FromURL (or ToURL) which should have the scheme, rather than the cached data. And no new APIs needed. For a global plugins it’s less obvious, but same issues o think? — Leif > On Sep 28, 2020, at 20:05, Leif Hedstrom <zw...@apache.org> wrote: > > The point here being to make a new API that replaces the old, without > breaking compatibility? And this new API has special semantics on a cache hit > vs cache miss? > > This seems pretty convoluted, making it difficult for plugin writers to use > the right API... > > — Leif > >> On Sep 28, 2020, at 19:49, Brian Neradt <brian.ner...@gmail.com> wrote: >> >> +1 >> >> Traffic Dump can make use of this. >> >>> On Mon, Sep 28, 2020 at 7:38 PM Walt Karas <wka...@verizonmedia.com.invalid> >>> wrote: >>> >>> This should get the scheme for the request. This differs from >>> `TSUrlSchemeGet` in that it gets the scheme even if it is not in the URL of >>> the request. For most proxy requests, the ATS core will remove the host and >>> scheme in the request while tracking it internally. In such a case a plugin >>> cannot discover that information, a problem this API would fix. >>> >>> If the scheme is in the request URL, return that. Otherwise return a scheme >>> that corresponds to the internally stored scheme. >>> >> >> >> -- >> "Come to Me, all who are weary and heavy-laden, and I will >> give you rest. Take My yoke upon you and learn from Me, for >> I am gentle and humble in heart, and you will find rest for >> your souls. For My yoke is easy and My burden is light." >> >> ~ Matthew 11:28-30
