There's also an interesting design doc referenced in that issue:
https://docs.google.com/document/d/1WPuim_GzhfdsnIj_tf-fIeutK0jO4aVQfVrLJFoLN3g/view#
Otto
Op ma 11 feb. 2019 om 23:21 schreef Leif Hedstrom :
> Since Peach is a slacker (or packing up boxes, not sure which), I’m
> sending this on
Since Peach is a slacker (or packing up boxes, not sure which), I’m sending
this on his behalf. This issue and PR is pretty interesting, and inline with
what we discussed at the Cork summit about how ATS and Envoy can integrate:
https://github.com/envoyproxy/envoy/issues/868
htt
Id agree with this. Its easy enough to always get the pristine url by just
making the api call. However getting the remapped url is not as easy. So it
makes sense that the remapped becomes the default and if any plugin needs the
pristine then it can get it anyway
On 2/11/19, 1:42 PM, "Gancho
I looked into the issues #4929, #4026, #2877 and PR #4531 which are all related
to this proposal about TSRemapRequestInfo::requestUrl (requestUrl for short)
and plugin ordering and I would like to revive the thread. (links to issues,
PRs, IRC logs referenced at the end of this email)
I definit
> Also, it's already very easy to write code that asserts later on. Trying
scheduling a TSCont that doesn't have a mutex.
A little off-topic: There are already several useful TS API functions that
require a mutex. Currently the plugin author must be diligent in reading
the documentation to learn w
Putting a blocking lock on those calls will eliminate the advantages we got
from moving to 1.1.1 from 1.0.2 in terms of lock contention. It will mean
people will write plugins with locks, put them on a TLS hook, and then
complain "ATS sucks, it's so slow doing TLS".
Also, it's already very easy to
