Technically the behavior works out fine for my production use case because the origin and the authorizing service are the same host. I noticed the socket connection wasn't changing when I wanted to use an isolated test environment and just hard coded the sockaddr ip address in (but didn't update the remap entry). I *could* imagine a use case where the authorizing web service resides on a different server than the origin and this behavior would present a problem. For the time being I think I'll be able to work with it but it was not immediately obvious what was going on. I just wanted to doublecheck with you guys.
On Jul 19, 2012, at 2:49 PM, Leif Hedstrom <[email protected]> wrote: > On 7/19/12 1:23 PM, Christopher Arnold wrote: >> I'm working on a trafficserver plugin that performs a basic auth check for >> specific types of files we'd like served from cache (sort of like the >> basic-auth plugin example). My plugin takes the existing http request, >> modifies the http method from GET to HEAD and then initiates a >> TSHttpConnect(addr) for a specific authentiation service addr address. >> Despite passing a hardcoded addr parameter to TSHttpConnect() it appears >> that my http connection is being made to the origin server/port referenced >> in my modified http request. Does anyone know if this is expected behavior? >> I'm a little thrown off by the behavior I'm observing in my plugin. >> > > TSHttpConnect() goes through the HttpSM, and as such, I *think* it's also > going through Remapping. Could that be a problem? > > -- Leif >
