You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Nick Kew (Commented) (JIRA)" <ji...@apache.org> on 2011/12/19 02:16:36 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=13171992#comment-13171992 ] 

Nick Kew commented on TS-998:
-----------------------------

Relatively simple to fix the narrow issue as reported at the level of http_hdr_print.  Just returning the buffer from the heap arg and its length is exactly what my plugin wants.

But this is a broader bug.  It manifests also in the error log, in messages like:

20111219.00h26m28s RESPONSE: sent 127.0.0.1 status 404 (Not Found on Accelerator) for 'http:///'

Here the critical traceback is:
#0  url_print (url=0xb6b64a08, buf_start=0xb6b24c15 "http://IVDIWF/F5W", 
    buf_length=8, buf_index_inout=0xb728f730, 
    buf_chars_to_skip_inout=0xb728f72c) at URL.cc:1534
#1  0x0823a7de in url_string_get (url=0xb6b64a08, arena=0xb1cf1ae0, 
    length=0x0, heap=0xb6b64808) at URL.cc:594
#2  0x08113e7e in URL::string_get (this=0xb1cf2280, 
    arena_or_null_for_malloc=0xb1cf1ae0, length=0x0) at ./hdrs/URL.h:405
#3  0x081ca4ea in HttpTransact::build_error_response (s=0xb1cf1ad8, 
    status_code=HTTP_STATUS_NOT_FOUND, 
    reason_phrase_or_null=0x832266c "Not Found on Accelerator", 
    error_body_type=0x8322656 "urlrouting#no_mapping", 
    format=0x8322634 "Your requested URL was not found.")
    at HttpTransact.cc:8058

The logic of url_print eludes me completely: under what circumstances do we ever want to build a URL that includes pseudo-components such as username/password?
                
> 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
>             Fix For: 3.1.2
>
>
> 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