[jira] [Updated] (TS-1038) TSHttpTxnErrorBodySet() can leak memory (pt 2)
[ https://issues.apache.org/jira/browse/TS-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1038: -- Fix Version/s: 3.1.2 Assignee: William Bardwell Cool! William, I'm assigning this to you, would you mind reviewing and landing this? If you can't (I know you just had babies, congrats!), just reassign it to me. TSHttpTxnErrorBodySet() can leak memory (pt 2) -- Key: TS-1038 URL: https://issues.apache.org/jira/browse/TS-1038 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: William Bardwell Fix For: 3.1.2 Attachments: TSHttpTxnErrorBodySet.patch TS-826 resolved a memory leak with TSHttpTxnErrorBodySet but it appears that mimetype is still being leaked. See HttpSM::setup_internal_transfer line 5416 which frees internal_msg_buffer_type...it's expected that mimetype was malloced since clearly it's being freed. So that means there is still a memory leak in TSHttpTxnErrorBodySet(). Patch included. -- 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
[jira] [Commented] (TS-1045) PATCH: add new TSFetchHdrGet API
[ https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13165434#comment-13165434 ] Brian Geffon commented on TS-1045: -- Your example is not a TSFetchURL request, it looks like a request from the browser for favicon.ico. It should work if it's a TSFetchURL request. PATCH: add new TSFetchHdrGet API Key: TS-1045 URL: https://issues.apache.org/jira/browse/TS-1045 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: James Peach Priority: Minor Attachments: 0007-Add-new-public-API-TSFetchHdrGet.patch TSFetchUrl does not provide any way to get the headers from the result. This patch adds a new API TSFetchHdrGet(), which is analogous to TSFetchRespGet() and returns the headers. -- 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
[jira] [Created] (TS-1046) Add possibility to extend tsxs command line for -Iincludes
Add possibility to extend tsxs command line for -Iincludes -- Key: TS-1046 URL: https://issues.apache.org/jira/browse/TS-1046 Project: Traffic Server Issue Type: Improvement Components: Build Affects Versions: 3.1.1, 3.0.2 Reporter: Igor Galić Assignee: Igor Galić Fix For: 3.1.2 Already commited in r1212075 -- 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
[jira] [Commented] (TS-1045) PATCH: add new TSFetchHdrGet API
[
https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13165819#comment-13165819
]
James Peach commented on TS-1045:
-
Nope, my example is definitely a TSFetchURL() request. The plugin I'm
experimenting with is a simple proxy, so when I get a browser request, I make a
corresponding TSFetchURL request.
TSFetchRespGet() returns the response body. If I apply your example code above,
TSHttpHdrParseResp() returns TS_PARSE_CONT. This is a bogus result, because at
the time of the call I'm handling the TSFetchURL() success event so I actually
have all the data. Additionally, I would really expect TSHttpHdrParseResp() to
return TS_PARSE_ERROR because it's being asked to return the body.
Hacked up code looks like this:
TSHttpParser parser = TSHttpParserCreate();
TSMBuffer buf = TSMBufferCreate();
TSMLoc hdrLoc = TSHttpHdrCreate(buf);
body = TSFetchRespGet(txn, len);
char * start;
char * end;
start = body;
end = body + len;
TSHttpHdrTypeSet(buf, hdrLoc, TS_HTTP_TYPE_RESPONSE);
TSParseResult ret;
ret = TSHttpHdrParseResp(parser, buf, hdrLoc,
(const char **)start, (const char *)end);
debug_protocol(TSHttpHdrParseResp = %d, ret);
if (ret != TS_PARSE_DONE) {
return;
}
And in the debugger, we see:
Breakpoint 1, send_http_txn_result (stream=0x1014069f0, txn=0x1030a50d0) at
stream.cc:297
297 TSHttpParser parser = TSHttpParserCreate();
(gdb) n
298 TSMBuffer buf = TSMBufferCreate();
(gdb) n
299 TSMLoc hdrLoc = TSHttpHdrCreate(buf);
(gdb) n
301 body = TSFetchRespGet(txn, len);
(gdb) n
305 start = body;
(gdb) p body
$1 = 0x101171460 htmlbodyh1It works!/h1/body/html
The code in FetchSM::process_fetch_read() is a bit confusing to me; I'm not
very familiar with ATS internals. On TS_EVENT_VCONN_READ_READY, resp_reader
consumes bytes twice in process_fetch_read() and then again in
client_response_hdr.parse_resp(). By inspection I would have thought that this
would over-consume, causing bytes to be skipped but that doesn't seem to
happen. At any rate, it reliably returns only the response body.
PATCH: add new TSFetchHdrGet API
Key: TS-1045
URL: https://issues.apache.org/jira/browse/TS-1045
Project: Traffic Server
Issue Type: Improvement
Components: HTTP
Reporter: James Peach
Priority: Minor
Attachments: 0007-Add-new-public-API-TSFetchHdrGet.patch
TSFetchUrl does not provide any way to get the headers from the result. This
patch adds a new API TSFetchHdrGet(), which is analogous to TSFetchRespGet()
and returns the headers.
--
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
