You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Alan M. Carroll (Commented) (JIRA)" <ji...@apache.org> on 2011/11/15 21:32:51 UTC

[jira] [Commented] (TS-998) Broken ClientReq in TSAPI

    [ https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13150748#comment-13150748 ] 

Alan M. Carroll commented on TS-998:
------------------------------------

This is a side effect of forward transparency. The original logic assumed that all of the parts of the URL are in the first line of the request, the URL portion of which is represented as the URL class, which contains a MIME like pointer to the host. In a request like this, that never gets set because there's no host in the URL. I have put in some hacks to get around this (when I was not so familiar with the codebase) but it was really just a bunch of patches in various places (e.g., the "effective URL" calls and related stuff). I wonder now if it might not work to have the HTTP header parser reach in to the URL object and set these when it finds the HOST field. That presumes that (1) the original ("pristine") URL is stored somewhere and (2) the MIME and URL memory is contemporaneous.

On a more local level, this output is created in proxy/hdrs/URL.cc - url_print(). It always prints out the scheme (e.g. "http") followed by "://". Tweaking this might well have other side effects, so it might be better to look at proxy/hdrs/HTTP.cc - http_hdr_print and fiddle there.

Anyway, those are places to start.
                
> Broken ClientReq in TSAPI
> -------------------------
>
>                 Key: TS-998
>                 URL: https://issues.apache.org/jira/browse/TS-998
>             Project: Traffic Server
>          Issue Type: Bug
>    Affects Versions: 3.0.1
>         Environment: any
>            Reporter: Nick Kew
>            Assignee: Alan M. Carroll
>
> Extracting a Request using TSHttpTxnClientReqGet API yields a bogus Request line.
> Expected behaviour: In a PRE_REMAP hook it should return the client request line and headers, ideally verbatim.
> Observed behaviour: "http://" is prepended to the request URL:
>   GET /path/ HTTP/1.1
> becomes
>   GET http:///path/ HTTP/1.1
> (yes, that's three slashes)
> Pseudo-code to reproduce from a PRE_REMAP hook:
>   TSHttpTxnClientReqGet(txnp, &buf, &hdr);
>   TSHttpHdrPrint(buf, hdr, iobuf);
>   reader = TSIOBufferReaderAlloc(iobuf);
>   block = TSIOBufferReaderStart(reader);
>   len = TSIOBufferBlockReadAvail(block, reader);
>   data = TSIOBufferBlockReadStart(block, reader, &len);
> Now examine the contents of data.
> Assigned to AMC as suggested yesterday on-list.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira