> 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 :) > > >> On Sep 7, 2016, at 7:38 PM, James Peach <jpe...@apache.org> wrote: >> >> >>> On Sep 7, 2016, at 6:39 PM, Sudheer Vinukonda >>> <sudheervinuko...@yahoo.com.INVALID> wrote: >>> >>> Spdy/H2 are different - they also have a stream flag set which is handled >>> differently in FetchSM. >> >> This proposal doesn’t touch FetchSM, since the TSFetchUrl API is not >> extensible in any meaningful way (I’d argue it is totally broken). Are you >> referring to the TS_FETCH_FLAGS_STREAM flag? That doesn’t apply here because >> there’s no API change for TSFetchUrl. >> >>> >>>> On Sep 7, 2016, at 6:27 PM, James Peach <jpe...@apache.org> wrote: >>>> >>>> >>>>> On Sep 7, 2016, at 5:48 PM, Sudheer Vinukonda >>>>> <sudheervinuko...@yahoo.com.INVALID> wrote: >>>>> >>>>> Can you describe the real purpose of allowing to change if a transaction >>>>> is external/internal - for example, is it merely for recording/metrics or >>>>> is it for a more significant functional purpose? >>>> >>>> It is both. If a request is logically from a client then the @internal >>>> remap.config filter should deny, the stale_while_revalidate plugin should >>>> not ignore it, and it should be generally treated as if the protocol >>>> plugin did not intermediate. “internal” carries the string connotation >>>> that this is a trusted or special transaction, which is not true for >>>> protocol plugins. >>>> >>>>> >>>>> Atleast, in the current implementation, allowing arbitrary control of the >>>>> internal state of a txn sounds dangerous to me - I recall some funky >>>>> handling of some headers (Connection/Keep Alive) and some special >>>>> handling for POST method etc. This API may expose problems from that code. >>>> >>>> I don’t think this is any different from allowing SPDY or HTTP/2 to mark >>>> their transactions as non-internal. >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Sudheer >>>>> >>>>>> On Sep 7, 2016, at 5:24 PM, James Peach <jpe...@apache.org> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> It is common to write protocol plugins that accept a non-HTTP protocol >>>>>> and generate HTTP request using TSHttpConnectWithPluginId(). In this >>>>>> case, although the HTTP transaction is technically an internal >>>>>> transaction, it is logically external since it is generated directly on >>>>>> behalf of clients. To address this, I'd like to propose an API to allow >>>>>> plugins to toggle whether a transaction is considered internal or not. >>>>>> >>>>>> tsapi void TSVConnInternalSet(TSVConn connp, int internal); >>>>>> >>>>>> The sample usage is straightforward: >>>>>> >>>>>> TSVConn vc = TSHttpConnectWithPluginId(addr, "plugin-name", 0); >>>>>> TSVConnInternalSet(vc, false); >>>>>> >>>>>> The corresponding implementation is >>>>>> https://github.com/apache/trafficserver/pull/986 and the Jira ticket is >>>>>> https://issues.apache.org/jira/browse/TS-4825. I'll add a manual page >>>>>> before committing. >>>>>> >>>>>> thanks, >>>>>> James >>
