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
