> On Sep 8, 2016, at 7:55 AM, Sudheer Vinukonda > <sudheervinuko...@yahoo.com.INVALID> wrote: > > > >> On Sep 7, 2016, at 10:09 PM, James Peach <jpe...@apache.org> wrote: >> >> >>> On Sep 7, 2016, at 9:16 PM, Sudheer Vinukonda >>> <sudheervinuko...@yahoo.com.INVALID> wrote: >>> >>> >>> >>>> On Sep 7, 2016, at 8:48 PM, James Peach <jpe...@apache.org> wrote: >>>> >>>> >>>>> On Sep 7, 2016, at 8:30 PM, Sudheer Vinukonda >>>>> <sudheervinuko...@yahoo.com.INVALID> wrote: >>>>> >>>>> I was replying to this - >>>>> >>>>>> "I don’t think this is any different from allowing SPDY or HTTP/2 to >>>>>> mark their transactions as non-internal." >>>>> >>>>> Marking Spdy/H2 as non-internal works because of the special handling >>>>> done via FetchSM. With the proposed new API, you are intending to mark >>>>> plugin generated requests as non-internal. My point is that it'd likely >>>>> cause issues. I'll try to find some time to dig and provide specifics. >>>> >>>> That would be great, because I’m struggling to see the special case here :) >>> >>> Below are a couple of recent related jiras, there's likely more. >>> >>> TS-3404 >>> TS-3777 >> >> Hmm, that’s a bit scary. It doesn’t seem like checking whether a transaction >> is internal is a very reliable fix. > > It's been a while, so I can't recall all the details well, but, basically yes > - the fix based on txn's internal state didn't seem reliable enough to me. I > thought I had a more comprehensive fix, but IIRC, jacksontj veto'ed it with > his fix he claimed to be running in prod :) > > Regardless, I believe the txn's internal state has been used to hack around a > bunch of (rather harmful) corner cases and allowing arbitrary plugin control > without cleaning up the hacks, could cause some (very bad) regressions. > >> I guess there is a corresponding hack for HTTP/2 so it can be non-internal >> and not fall into this hole? >> > > There well could be, but can't recall from the top of my head. I think it > might be a little different with Spdy/H2, since streams (txn), are > multiplexed at the connection level and the connections are generally > persistent (as opposed to plugin initiated "internal" requests which just > hang since there's no multiplexing involved).
Thanks for the info Sudheer. I filed TS-4836 to address fixing this up. In the meantime, I can get along with using TSHttpTxnPluginTagGet(), so I'll abandon this API until it is safe. J
