[jira] [Updated] (TS-1070) replace and deprecate TSFetchURL()
[
https://issues.apache.org/jira/browse/TS-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1070:
Fix Version/s: (was: 3.1.4)
3.3.0
Out of time for 3.2 release; punt to 3.3.
> replace and deprecate TSFetchURL()
> --
>
> Key: TS-1070
> URL: https://issues.apache.org/jira/browse/TS-1070
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 3.3.0
>
>
> TSFetchURL() has a number of shortcomings:
> 1. it's not cancellable
> 2. the event delivery is bizarre
> 3. it doesn't play nicely with the TSHttpHdr*() API.
> I propose the following API changes:
> typedef enum
> {
> ...
> TS_EVENT_FETCH_SUCCESS,
> TS_EVENT_FETCH_FAILURE
> } TSEvent;
> TSAction TSFetchResource(TSCont, TSMBuffer, TSLoc, const sockaddr *,
> TSFetchWakeUpOptions);
> TSFetchResource() takes a TSMBuffer/TSLoc pair that must contain the HTTP and
> MIME headers. If the HTTP method in the HTTP header is not GET, and a error
> will be reported.
> The continuation callback will be invoked with either TS_EVENT_FETCH_SUCCESS
> or TS_EVENT_FETCH_SUCCESS. For TS_EVENT_FETCH_SUCCESS, the edata pointer will
> be a HttpTxn pointer suitable for call TSFetchRespGet() or TSFetchHdrGet().
> For TS_EVENT_FETCH_FAILURE, I'd like to arrange a way to get the HTTP error
> code. Hopefully there is some existing precedent to follow.
> TSFetchResource() should be cancellable via the TSAction return value.
> I'm not sure whether TSFetchWakeUpOptions is really necessary, but if we
> eliminate this, I'd argue for a uint64_t flags parameter.
--
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] [Updated] (TS-1062) TSFetchUrl doesn't handle chunked encoding
[ https://issues.apache.org/jira/browse/TS-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1062: Fix Version/s: (was: 3.1.4) 3.2.0 Not a regression; push out to 3.2. > TSFetchUrl doesn't handle chunked encoding > -- > > Key: TS-1062 > URL: https://issues.apache.org/jira/browse/TS-1062 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: James Peach >Assignee: James Peach > Fix For: 3.2.0 > > > If you use TSFetchUrl() to fetch a resource and the response comes back with > chunked encoding, you are basically hosed. The caller never gets the SUCCESS > event because FetchSM does not know how to decode the body. There's no > content-length header and the origin server doesn't drop the TCP connection, > so we just sit there waiting for the response to finish forever (well until > the origin server drops the connection 10s later). -- 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] [Updated] (TS-1054) TSFetchUrl takes an address but does the DNS lookup anyway
[
https://issues.apache.org/jira/browse/TS-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1054:
Fix Version/s: (was: 3.1.4)
3.3.0
I won't have time to investigate for 3.2. Move out to 3.3.
> TSFetchUrl takes an address but does the DNS lookup anyway
> --
>
> Key: TS-1054
> URL: https://issues.apache.org/jira/browse/TS-1054
> Project: Traffic Server
> Issue Type: Bug
> Components: Performance
>Affects Versions: 3.0.2
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 3.3.0
>
>
> TSFetchUrl() takes an IP address as one of its arguments, so the API client
> has to resolve the hostname portion of any URL it wants to fetch. However
> once you get into the HTTP state machine, the host gets resolved again. One
> of these DNS queries is redundant for performance reasons. Additionally, the
> plugin might have some special knowledge about which IP address to use that
> the DNS resolver doesn't, in which case the result would be wrong.
> [Dec 14 20:36:29.414] Server {0x7fff7b5f9960} DIAG: (plugin) [1] http request
> (90 of 90 bytes):
> GET http://www.iana.org//_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.1
> accept: */*
> [Dec 14 20:36:29.415] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [init] FetchSM
> initialized for request with headers
> --
> GET http://www.iana.org//_css/2011.1/fonts/OpenSans-SemiBold.ttf HTTP/1.1
> accept: */*
> --
> [Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (FetchSM) [httpConnect]
> calling httpconnect write
> [Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Created
> PluginVCCore at 0x102872c00, active 0x102872c38, passive 0x102872e10
> [Dec 14 20:36:29.424] Server {0x7fff7b5f9960} DEBUG: (http_seq)
> HttpAccept:mainEvent] accepted connection
> [Dec 14 20:36:29.425] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] session
> born, netvc 0x102872e10
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] using
> accept inactivity timeout [120 seconds]
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (http_cs) [0] Starting
> transaction 1 using sm [0]
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> do_io_read for 0 bytes
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> do_io_read for -1 bytes
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> do_io_read for -1 bytes
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> do_io_write for 90 bytes
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc_event) [0] Passive:
> Received event 1
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> process_read_side
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> process_read_side; act_on 0
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> closed? 0 shutdown? 0
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc_event) [0] Active:
> Received event 1
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> process_read_side
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> process_read_side; act_on 0
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> closed? 0 shutdown? 0
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> process_write_side
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> process_write_side; act_on 90
> [Dec 14 20:36:29.436] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Active:
> process_write_side; added 90
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (FetchSM)
> [fetch_handler] calling fetch_plugin
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (FetchSM)
> [process_fetch_write] calling process write
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> process_read_side
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> process_read_side; act_on 90
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> process_read_side; added 90
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0]
> [HttpSM::main_handler, VC_EVENT_READ_READY]
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0]
> [&HttpSM::state_read_client_request_header, VC_EVENT_READ_READY]
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0] done parsing
> client request header
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (pvc) [0] Passive:
> reenable Read
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans) START
> HttpTransact::ModifyRequest
> [Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBU
[jira] [Updated] (TS-1085) traffic_shell enable command doesn't work
[ https://issues.apache.org/jira/browse/TS-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1085: Fix Version/s: (was: 3.1.4) 3.3.0 Maybe we will fix this by removing traffic_shell in 3.3. > traffic_shell enable command doesn't work > - > > Key: TS-1085 > URL: https://issues.apache.org/jira/browse/TS-1085 > Project: Traffic Server > Issue Type: Bug > Components: Management >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.0 > > > Let's try this as root: > blacko:trafficserver.git jpeach$ sudo /opt/ats/bin/traffic_shell > Successfully Initialized MgmtAPI in /opt/ats/var/trafficserver > % trafficserver> enable > Already Enabled > trafficserver> exit > Ok, to let's try as non-root: > blacko:trafficserver.git jpeach$ /opt/ats/bin/traffic_shell > [connect] ERROR (main_socket_fd 3): Permission denied > TSInit 5: Failed to initialize MgmtAPI in /opt/ats/var/trafficserver > [connect] ERROR (main_socket_fd 3): Permission denied > % trafficserver> enable > FATAL: ConfigCmd.cc:137: failed assert `enable_restricted_commands` > /opt/ats/bin/traffic_shell - STACK TRACE: > 0 libtsutil.3.dylib 0x00010cec8b8b ink_fatal_va + 283 > 1 libtsutil.3.dylib 0x00010cec8e94 ink_fatal + 356 > 2 libtsutil.3.dylib 0x00010cec66ff _ink_assert + 271 > 3 traffic_shell 0x00010ce253ab > _Z10Cmd_EnablePvP10Tcl_InterpiPPKc + 395 > 4 Tcl 0x00010cf34261 > TclInvokeStringCommand + 121 > 5 Tcl 0x00010cf360b7 > Tcl_GetMathFuncInfo + 2533 > 6 Tcl 0x00010cf36d14 > Tcl_GetMathFuncInfo + 5698 > 7 Tcl 0x00010cf370d2 Tcl_Eval + 42 > So either enable does nothing or it crashes. Seems like we should fix or > remove this. -- 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] [Updated] (TS-1147) deprecate records.config SSL configuration
[ https://issues.apache.org/jira/browse/TS-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1147: Fix Version/s: (was: 3.1.4) 3.1.5 Assignee: James Peach I'm going to investigate this for 3.1.5 (aka. 3.2). > deprecate records.config SSL configuration > -- > > Key: TS-1147 > URL: https://issues.apache.org/jira/browse/TS-1147 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Fix For: 3.1.5 > > > Since ssl_multicert.config is a strict superset of the SSL certificate > configuration in records.config, we should deprecate configuring SSL > certificates in records.config and make ssl_multicert.config the One True Way. -- 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] [Updated] (TS-1149) pretty up automake output
[ https://issues.apache.org/jira/browse/TS-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1149: Summary: pretty up automake output (was: pretty up automate output) > pretty up automake output > - > > Key: TS-1149 > URL: https://issues.apache.org/jira/browse/TS-1149 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: James Peach >Assignee: James Peach >Priority: Trivial > > automake is super ugly by default. Make it pretty. -- 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] [Updated] (TS-1144) fix out of tree builds
[ https://issues.apache.org/jira/browse/TS-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1144: Summary: fix out of tree builds (was: fox out of tree builds) > fix out of tree builds > -- > > Key: TS-1144 > URL: https://issues.apache.org/jira/browse/TS-1144 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: James Peach > > Fixes some minor issues in the build system when building sources in separate > directory than the obj files. -- 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] [Updated] (TS-1015) TSEvent is widely declared as int
[ https://issues.apache.org/jira/browse/TS-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1015: Component/s: Cleanup Yes, this would be really helpful! > TSEvent is widely declared as int > - > > Key: TS-1015 > URL: https://issues.apache.org/jira/browse/TS-1015 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Reporter: Nick Kew >Priority: Minor > Fix For: 3.1.5 > > > TSEvent is an enum, defined in ts.h. But in much of the code, TSEvent is > declared as type int. This makes it harder to follow/debug using tools like > *trace or gdb. > This may usefully be fixed as and when people encounter instances of it. -- 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] [Updated] (TS-1107) dynamically scale the number of net threads
[ https://issues.apache.org/jira/browse/TS-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1107: Affects Version/s: 3.3.0 Push out to 3.3 > dynamically scale the number of net threads > --- > > Key: TS-1107 > URL: https://issues.apache.org/jira/browse/TS-1107 > Project: Traffic Server > Issue Type: New Feature > Components: Core, Performance >Affects Versions: 3.3.0 >Reporter: James Peach >Priority: Minor > > The number of net threads is calculated once at startup, but we ought to > consider dynamically scaling the number of threads a runtime based on load. > zwoop: right, that's what I meant (keep a counter of how many times epoll had > no events, and treat that as an "idle" thread) > zwoop: probably a multiplier of some setting (thread_idle_seconds or some > such) > zwoop: this would be a cool feature, if you have the time for it ;) > zwoop: can keep the original calculations / settings as the "upper" limit I > think > zwoop: (the calculations can also easily be configured in records.config, so > that people can modify that upper limit) > zwoop: an ideal solution (backward compatible) would be to just add one new > setting, or some such, default to 0 (off). With > it not set, our normal logic applies. With it set, your stuff takes effect, > but cap it at whatever the other settings are. -- 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] [Updated] (TS-475) HTTP SM should support efficient byte range requests
[ https://issues.apache.org/jira/browse/TS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-475: --- Component/s: Cache > HTTP SM should support efficient byte range requests > > > Key: TS-475 > URL: https://issues.apache.org/jira/browse/TS-475 > Project: Traffic Server > Issue Type: Bug > Components: Cache, HTTP >Reporter: Leif Hedstrom >Priority: Critical > Fix For: 3.1.5 > > Attachments: diff.out > > > The cache has support for efficiently locate a particular range in the cached > object, but the HTTP SM does not support this. In order to make Range: > request efficient (particularly on large objects), the SM should support this > new cache feature. -- 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] [Updated] (TS-838) [GSoC] Create a port of mod_security as Apache TrafficServer plugin
[ https://issues.apache.org/jira/browse/TS-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-838: --- Labels: (was: gsoc2011) > [GSoC] Create a port of mod_security as Apache TrafficServer plugin > --- > > Key: TS-838 > URL: https://issues.apache.org/jira/browse/TS-838 > Project: Traffic Server > Issue Type: Wish > Components: Plugins >Reporter: Igor Galić > > ModSecurity is a Web Application Firewall (WAF), which is currently natively > implemented as Apache httpd module. > It is mostly used to protect multiple back-end applications from a single > entry point on a proxy-server. This alone makes Traffic Server the ideal > platform for a port. > For reference, see https://www.modsecurity.org/tracker/browse/MODSEC-250 -- 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] [Updated] (TS-841) support TLS NextProtocol negotiation
[ https://issues.apache.org/jira/browse/TS-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-841: --- Attachment: 0005-TS-841-support-TLS-NextProtocol-negotiation.patch 0004-TS-841-Load-plugins-after-opening-sockets.patch 0003-TS-841-Propagate-zero-length-read-events-through-SSL.patch 0002-TS-841-Sprinkle-some-const-pixie-dust-on-the-SSL-cla.patch 0001-TS-841-Move-SSLNetAccept-and-SSLNetProcessor-into-ep.patch Attached patches. > support TLS NextProtocol negotiation > > > Key: TS-841 > URL: https://issues.apache.org/jira/browse/TS-841 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP, SSL >Reporter: Leif Hedstrom >Assignee: James Peach > Fix For: 3.1.3 > > Attachments: > 0001-TS-841-Move-SSLNetAccept-and-SSLNetProcessor-into-ep.patch, > 0002-TS-841-Sprinkle-some-const-pixie-dust-on-the-SSL-cla.patch, > 0003-TS-841-Propagate-zero-length-read-events-through-SSL.patch, > 0004-TS-841-Load-plugins-after-opening-sockets.patch, > 0005-TS-841-support-TLS-NextProtocol-negotiation.patch > > > In order to make it possible to write protocol handlers like SPDY, we need to > negotiate NPN protocol before entering the HTTP SM. -- 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] [Updated] (TS-841) support TLS NextProtocol negotiation
[ https://issues.apache.org/jira/browse/TS-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-841: --- Summary: support TLS NextProtocol negotiation (was: Refactor SSL code to make it possible to perform NPN negotiation without entering the HTTP SM) Retitle and assign to me. I have this almost complete. > support TLS NextProtocol negotiation > > > Key: TS-841 > URL: https://issues.apache.org/jira/browse/TS-841 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP, SSL >Reporter: Leif Hedstrom >Assignee: James Peach > Fix For: 3.1.3 > > > In order to make it possible to write protocol handlers like SPDY, we need to > negotiate NPN protocol before entering the HTTP SM. -- 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] [Updated] (TS-1043) PATCH: teach TSFetchUrl to use the content-length to find the after_body event
[ https://issues.apache.org/jira/browse/TS-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1043: Fix Version/s: (was: 3.1.2) > PATCH: teach TSFetchUrl to use the content-length to find the after_body event > -- > > Key: TS-1043 > URL: https://issues.apache.org/jira/browse/TS-1043 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: James Peach >Assignee: James Peach > Attachments: > 0005-TSFetchUrl-use-content-length-to-fire-after_body-eve.patch > > > TSFetchUrl() does not fire the after_body event until the TCP connection is > closed. The fix is to check the content-length when we receive more bytes and > to fire the after_body event when all the byte are received. > This looks like https://issues.apache.org/jira/browse/TS-817 and possibly > https://issues.apache.org/jira/browse/TS-912 -- 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] [Updated] (TS-1045) PATCH: add new TSFetchHdrGet API
[ https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1045: Fix Version/s: (was: 3.1.2) > PATCH: add new TSFetchHdrGet API > > > Key: TS-1045 > URL: https://issues.apache.org/jira/browse/TS-1045 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Attachments: 0001-Add-new-public-API-TSFetchHdrGet.patch, > 0007-Add-new-public-API-TSFetchHdrGet.patch, TS-1045-formatting.diff > > > 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] [Updated] (TS-1083) initial SSL next protocol negotiation support
[ https://issues.apache.org/jira/browse/TS-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1083: Fix Version/s: 3.1.2 > initial SSL next protocol negotiation support > - > > Key: TS-1083 > URL: https://issues.apache.org/jira/browse/TS-1083 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Fix For: 3.1.2 > > Attachments: > 0001-Compile-time-detection-of-NextProtocolNegotiation-su.patch, > 0002-Initial-NPN-plumbing.patch > > > Initial autoconf support for detecting OpenSSL Next Protocol Negotiation > APIs. Advertise that we support HTTP/1.0 and HTTP/1.1. Because we do. -- 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] [Updated] (TS-1082) configure always clobbers optimiser flags
[ https://issues.apache.org/jira/browse/TS-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1082: Fix Version/s: 3.1.2 > configure always clobbers optimiser flags > - > > Key: TS-1082 > URL: https://issues.apache.org/jira/browse/TS-1082 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: Igor Galić >Priority: Minor > Fix For: 3.1.2 > > Attachments: 0001-TS-1082-Fix-optimizer-flags-detection.patch > > > If the builder specifies optimizer flags, don't flip the default to -O3. > Current behaviour is to always use -O3, since the check to disable this > doesn't work. I believe the intention if for the builder to be able to do > "CXXFLAGS=-O1 ./configure" and have the build use -O1. -- 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] [Updated] (TS-1082) configure always clobbers optimiser flags
[ https://issues.apache.org/jira/browse/TS-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1082: Attachment: 0001-TS-1082-Fix-optimizer-flags-detection.patch Updated INSTALL with Igor's feedback. Restored support for Sun Studio -xO option and commented it ;) > configure always clobbers optimiser flags > - > > Key: TS-1082 > URL: https://issues.apache.org/jira/browse/TS-1082 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Attachments: 0001-TS-1082-Fix-optimizer-flags-detection.patch > > > If the builder specifies optimizer flags, don't flip the default to -O3. > Current behaviour is to always use -O3, since the check to disable this > doesn't work. I believe the intention if for the builder to be able to do > "CXXFLAGS=-O1 ./configure" and have the build use -O1. -- 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] [Updated] (TS-1082) configure always clobbers optimiser flags
[ https://issues.apache.org/jira/browse/TS-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1082: Attachment: (was: 0001-TS-1082-Fix-optimizer-flags-detection.patch) > configure always clobbers optimiser flags > - > > Key: TS-1082 > URL: https://issues.apache.org/jira/browse/TS-1082 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Attachments: 0001-TS-1082-Fix-optimizer-flags-detection.patch > > > If the builder specifies optimizer flags, don't flip the default to -O3. > Current behaviour is to always use -O3, since the check to disable this > doesn't work. I believe the intention if for the builder to be able to do > "CXXFLAGS=-O1 ./configure" and have the build use -O1. -- 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] [Updated] (TS-1084) enable compile-time format string checking
[ https://issues.apache.org/jira/browse/TS-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1084: Attachment: 0001-TS-1084-Add-format-string-checking.patch Attached new patch that builds on Linux; well at least it builds on Ubuntu 9 (?) > enable compile-time format string checking > -- > > Key: TS-1084 > URL: https://issues.apache.org/jira/browse/TS-1084 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: James Peach >Assignee: Leif Hedstrom >Priority: Minor > Attachments: 0001-TS-1084-Add-format-string-checking.patch > > > Add format string checking. > > Add format string checking to internal and external APIs that take > a printf(3) format string. No functional changes. > > Fix all the resulting warnings > - time_t is formatted as long long for portability > - size_t became %zu > - pointers all became %p -- 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] [Updated] (TS-1084) enable compile-time format string checking
[ https://issues.apache.org/jira/browse/TS-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1084: Attachment: (was: 0001-Add-format-string-checking.patch) > enable compile-time format string checking > -- > > Key: TS-1084 > URL: https://issues.apache.org/jira/browse/TS-1084 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: James Peach >Assignee: Leif Hedstrom >Priority: Minor > > Add format string checking. > > Add format string checking to internal and external APIs that take > a printf(3) format string. No functional changes. > > Fix all the resulting warnings > - time_t is formatted as long long for portability > - size_t became %zu > - pointers all became %p -- 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] [Updated] (TS-1084) enable compile-time format string checking
[ https://issues.apache.org/jira/browse/TS-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1084: Attachment: 0001-Add-format-string-checking.patch Tested on OS X; there's a reasonable probability of build breakage on other platforms. This will need a couple of passes through the build farm to shake it out. > enable compile-time format string checking > -- > > Key: TS-1084 > URL: https://issues.apache.org/jira/browse/TS-1084 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: James Peach >Priority: Minor > Attachments: 0001-Add-format-string-checking.patch > > > Add format string checking. > > Add format string checking to internal and external APIs that take > a printf(3) format string. No functional changes. > > Fix all the resulting warnings > - time_t is formatted as long long for portability > - size_t became %zu > - pointers all became %p -- 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] [Updated] (TS-1083) initial SSL next protocol negotiation support
[ https://issues.apache.org/jira/browse/TS-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1083: Attachment: 0002-Initial-NPN-plumbing.patch 0001-Compile-time-detection-of-NextProtocolNegotiation-su.patch Attached 1 patches. First just adds the autoconf checks. Second adds make the calls and advertises the HTTP protocol. Careful, if you build on OS X with MacPorts /opt/local/bin will be linked before /usr/local/ssl and NPN support won't be detected. This is difficult to avoid. > initial SSL next protocol negotiation support > - > > Key: TS-1083 > URL: https://issues.apache.org/jira/browse/TS-1083 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Attachments: > 0001-Compile-time-detection-of-NextProtocolNegotiation-su.patch, > 0002-Initial-NPN-plumbing.patch > > > Initial autoconf support for detecting OpenSSL Next Protocol Negotiation > APIs. Advertise that we support HTTP/1.0 and HTTP/1.1. Because we do. -- 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] [Updated] (TS-1082) configure always clobbers optimiser flags
[ https://issues.apache.org/jira/browse/TS-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1082: Attachment: 0001-TS-1082-Fix-optimizer-flags-detection.patch Attach patch. > configure always clobbers optimiser flags > - > > Key: TS-1082 > URL: https://issues.apache.org/jira/browse/TS-1082 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Attachments: 0001-TS-1082-Fix-optimizer-flags-detection.patch > > > If the builder specifies optimizer flags, don't flip the default to -O3. > Current behaviour is to always use -O3, since the check to disable this > doesn't work. I believe the intention if for the builder to be able to do > "CXXFLAGS=-O1 ./configure" and have the build use -O1. -- 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] [Updated] (TS-1041) PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet
[ https://issues.apache.org/jira/browse/TS-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1041: Attachment: 0001-Ensure-sockaddr-length-is-always-populated.patch Updated patch that includes configure checks. > PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet > -- > > Key: TS-1041 > URL: https://issues.apache.org/jira/browse/TS-1041 > Project: Traffic Server > Issue Type: Improvement > Components: DNS > Environment: Mac OS X 10.7 >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Fix For: 3.1.2 > > Attachments: 0001-Ensure-sockaddr-length-is-always-populated.patch, > 0003-Ensure-sockaddr-length-is-always-populated.patch > > > The sockaddr returned by TSHostLookupResultAddrGet() does not always get it's > sa_len field populated correctly. This patch guarantees to populate it to the > correct value so that plugin authors can rely on that field when copying the > TSHostLookupResultAddrGet() result. -- 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] [Updated] (TS-1045) PATCH: add new TSFetchHdrGet API
[ https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1045: Attachment: 0001-Add-new-public-API-TSFetchHdrGet.patch Updated TSFetchHdrGet() patch that adds the error checking from TSFetchPageRespGet(). It also deprecates FSFetchPageRespGet(). > 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 >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 3.1.2 > > Attachments: 0001-Add-new-public-API-TSFetchHdrGet.patch, > 0007-Add-new-public-API-TSFetchHdrGet.patch, TS-1045-formatting.diff > > > 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] [Updated] (TS-1045) PATCH: add new TSFetchHdrGet API
[ https://issues.apache.org/jira/browse/TS-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1045: Attachment: 0007-Add-new-public-API-TSFetchHdrGet.patch > 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] [Updated] (TS-1044) PATCH: Fix TSVConn{Read,Write}VIOGet in UnixNetVConnection.
[
https://issues.apache.org/jira/browse/TS-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1044:
Attachment: 0006-Fix-TSVConn-Read-Write-VIOGet-in-UnixNetVConnection.patch
> PATCH: Fix TSVConn{Read,Write}VIOGet in UnixNetVConnection.
> ---
>
> Key: TS-1044
> URL: https://issues.apache.org/jira/browse/TS-1044
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
> Attachments:
> 0006-Fix-TSVConn-Read-Write-VIOGet-in-UnixNetVConnection.patch
>
>
> UnixNetVConnection does not actually implement the virtual interface
> necessary to support the TSVConn{Read,Write}VIOGet() APIs. Even worse, the
> API layer assumes that this can't fail and proceeds to return a pointer to
> stack junk.
> This patch implements TSVConn{Read,Write}VIOGet() for UnixNetVConnection and
> allows the API to return NULL.
--
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] [Updated] (TS-1043) PATCH: teach TSFetchUrl to use the content-length to find the after_body event
[ https://issues.apache.org/jira/browse/TS-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1043: Attachment: 0005-TSFetchUrl-use-content-length-to-fire-after_body-eve.patch > PATCH: teach TSFetchUrl to use the content-length to find the after_body event > -- > > Key: TS-1043 > URL: https://issues.apache.org/jira/browse/TS-1043 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: James Peach > Attachments: > 0005-TSFetchUrl-use-content-length-to-fire-after_body-eve.patch > > > TSFetchUrl() does not fire the after_body event until the TCP connection is > closed. The fix is to check the content-length when we receive more bytes and > to fire the after_body event when all the byte are received. > This looks like https://issues.apache.org/jira/browse/TS-817 and possibly > https://issues.apache.org/jira/browse/TS-912 -- 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] [Updated] (TS-1042) PATCH: correct debug message in FetchSM
[ https://issues.apache.org/jira/browse/TS-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1042: Attachment: 0004-Fix-FetchSM-debugging-message.patch > PATCH: correct debug message in FetchSM > --- > > Key: TS-1042 > URL: https://issues.apache.org/jira/browse/TS-1042 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: James Peach >Priority: Minor > Attachments: 0004-Fix-FetchSM-debugging-message.patch > > > In the FetchSM module, there is a debug message that can walk off the end of > the buffer. This patch corrects that by limiting the printed string to the > known length. -- 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] [Updated] (TS-1041) PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet
[ https://issues.apache.org/jira/browse/TS-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1041: Attachment: 0003-Ensure-sockaddr-length-is-always-populated.patch > PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet > -- > > Key: TS-1041 > URL: https://issues.apache.org/jira/browse/TS-1041 > Project: Traffic Server > Issue Type: Improvement > Components: DNS > Environment: Mac OS X 10.7 >Reporter: James Peach >Priority: Minor > Attachments: 0003-Ensure-sockaddr-length-is-always-populated.patch > > > The sockaddr returned by TSHostLookupResultAddrGet() does not always get it's > sa_len field populated correctly. This patch guarantees to populate it to the > correct value so that plugin authors can rely on that field when copying the > TSHostLookupResultAddrGet() result. -- 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] [Updated] (TS-1040) PATCH: teach TSHostLookup to use const
[ https://issues.apache.org/jira/browse/TS-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1040: Attachment: 0002-TSHostLookup-should-take-const-hostname-argument.patch > PATCH: teach TSHostLookup to use const > -- > > Key: TS-1040 > URL: https://issues.apache.org/jira/browse/TS-1040 > Project: Traffic Server > Issue Type: Improvement > Components: DNS >Reporter: James Peach >Priority: Minor > Attachments: > 0002-TSHostLookup-should-take-const-hostname-argument.patch > > > This patch improves the TSHostLookup() API by specifying it's hostname > argument as const. This reduces the number of casts required of plugin > authors. > The new prototype is: > tsapi TSAction TSHostLookup(TSCont contp, const char* hostname, size_t > namelen) -- 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] [Updated] (TS-1039) PATCH: use pcre-config to find libpcre
[ https://issues.apache.org/jira/browse/TS-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1039: Attachment: 0001-Use-pcre-config-to-find-libpcre.patch > PATCH: use pcre-config to find libpcre > -- > > Key: TS-1039 > URL: https://issues.apache.org/jira/browse/TS-1039 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: James Peach >Priority: Minor > Attachments: 0001-Use-pcre-config-to-find-libpcre.patch > > > This patch uses pcre-config to determine the compilation options needed to > use libpcre. This is an improvement over the exiting configure arguments > since it will work without user intervention in more circumstances. The > existing configuration option still works as expected for compatibility > reasons. -- 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
