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); > > >
