As indicated in my original email, there is no way to call it all the time. You can't call the existing API release function when using TSRemap(From|To)UrlGet().
The need to delete/release introduces ownership (owning vs. weak references/pointers) which can be complex and should be avoided when possible. On Wed, Sep 4, 2019 at 9:16 PM vijay mamidi <vijaybhaskar.mam...@gmail.com> wrote: > I am sorry for the delayed response. > > I am -0 on this. I think having one API which is supposed to be called > all the time(even if it is a no-op) is less complicated than having an API > to be called at certain times. > > Thanks, > Vijay > > On Tue, Sep 3, 2019 at 3:56 PM Walt Karas <wka...@verizonmedia.com> wrote: > >> OK then barring further input, I guess I will replace TSMLoc with >> TSMsgLoc, >> TSUrlLoc and TSMimeFldLoc. TSHandleMLocRelease() will be removed, >> TSHandleMimeFldLocRelease() will be added. TS API functions that >> currently >> deal with MIME header mlocs will be changed to deal with TSMsgLoc. >> >> Since this goes beyond adding a function to the C API, the change can't be >> backported into 9. Thus it won't be possible to backport >> https://github.com/apache/trafficserver/pull/5812 into 9. >> >> On Tue, Sep 3, 2019 at 12:14 PM Walt Karas <wka...@verizonmedia.com> >> wrote: >> >> > Currently a TSMLoc can be a message, a MIME header, a URL, or a MIME >> > header field. It does make sense to have TS API functions that operate >> on >> > a MIME header, but can also accept a message mloc and retrieve the MIME >> > header object from it. InkAPI.cc is able to do run-time validation that >> > the right sort of mloc is passed to TS API functions. So it isn't so >> cut >> > and dried that it's worth forcing all the rework to existing plugins to >> > break up TSMLoc into multiple types. >> > >> > On Sat, Aug 24, 2019 at 8:36 AM Alan Carroll < >> > solidwallofc...@verizonmedia.com> wrote: >> > >> >> I thought when we discussed this you were going to segregate these by >> >> type. >> >> One might consider splitting the current TSMLoc in to TSHdrLoc and >> TSMLoc, >> >> the latter requiring a release. I agreed with your view that it was >> best >> >> to >> >> have distinct types to avoid confusion about what should be passed to >> >> which >> >> API functions. >> >> >> >> On Thu, Aug 22, 2019 at 12:06 PM Walt Karas <wka...@verizonmedia.com >> >> .invalid> >> >> wrote: >> >> >> >> > Nominally, plugins are supposed to call TSHandleMLocRelease() for all >> >> > TSMLoc values returned by the API. But in practice it is only >> >> necessary to >> >> > call it for TSMLoc values that refer to MIME header fields: >> >> > >> >> > >> >> > >> >> >> https://github.com/apache/trafficserver/blob/d75af6f2eb6c63aa216111bd7f477f1f4c775580/src/traffic_server/InkAPI.cc#L2046 >> >> > >> >> > This adds significant complexity to plugin code. In some cases, the >> API >> >> > itself forces plugins to ignore the nominal need to call the release >> >> > function for TSMLoc values that don't refer for MIME header >> >> > fields. TSRemapFromUrlGet() and TSRemapToUrlGet() returns TSMLoc >> >> values, >> >> > but not a TSMBuffer value, making it impossible release the TSMLoc >> >> values. >> >> > I propose adding the API function: >> >> > >> >> > void TSMimeHdrFieldMLocRelease(TSMbuffer, TSMLoc); >> >> > >> >> >> > >> >
