[
https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421263#comment-13421263
]
Nick Kew commented on TS-998:
-----------------------------
Yes, we have a workaround, and that's even been simplified recently. I gave up
on it when it became clear that this bug is considered a Feature by some
established users, so a simple/clean fix wouldn't be accepted.
I do recollect this going through a couple of iterations to try and coexist
with the 'Feature'. From your last comment it's evident it got left in an
Abandon state. So I guess it's time to abandon the fix and mark the bug
WONTFIX?
> 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: Nick Kew
> Fix For: 3.3.1
>
>
> 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
