Correct. That should be fixed as well, but probably in a separate PR.
On Wed, Oct 7, 2020 at 6:53 PM Walt Karas
wrote:
> In testing the current code behavior, I've discovered that
> TSHttpHdrEffectiveUrlBufGet() omits the scheme when called on the request
> to server:
>
> Transaction: event=TS_E
In testing the current code behavior, I've discovered that
TSHttpHdrEffectiveUrlBufGet() omits the scheme when called on the request
to server:
Transaction: event=TS_EVENT_HTTP_SEND_REQUEST_HDR
TSHttpTxnEffectiveUrlStringGet(): http://127.0.0.1:61000/
TSHttpHdrEffectiveUrlBufGet(): 127.0.0.1:610
The problem arises on the proxy request, not the inbound request.
TSUrlRawSchemeGet should return an empty string for the first case.
On Tue, Oct 6, 2020 at 3:22 PM Walt Karas
wrote:
> So, when I call the current TSUrlSchemeGet() for these two requests:
>
> printf "GET / HTTP/1.1\r\nHost: mYhOs
So, when I call the current TSUrlSchemeGet() for these two requests:
printf "GET / HTTP/1.1\r\nHost: mYhOsT.teSt:61000\r\n\r\n" | nc localhost
61001
printf "GET http://mYhOsT.teSt:61000/ HTTP/1.1\r\n\r\n" | nc localhost 61001
I get "http" for both. Does that mean it's already working as desired?
There has been a lot of discussion on this and the related change for the
URL port. You can see some of this on the ASF slack channel, but I will
summarize in this note.
Leif objected to this change and the current compromise is to
1. Change the current TSUrlSchemeGet to do what was proposed for
I don't see how this would depend on a cache hit or miss. If two requests
map to the same object, that's the cache key, not the request scheme. This
returns the scheme in hdr->m_http->req.m_url_impl.scheme or
hdr->m_http->req.m_url_impl.m_url_type if the former is nullptr.
The point here is to pro
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 rema
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,
+1
Traffic Dump can make use of this.
On Mon, Sep 28, 2020 at 7:38 PM Walt Karas
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
