[jira] [Created] (TS-1210) remove 3.0.x deprecated APIs
remove 3.0.x deprecated APIs Key: TS-1210 URL: https://issues.apache.org/jira/browse/TS-1210 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: James Peach Fix For: 3.1.4 We should remove the following APIs that were deprecated in 3.0: tsapi TSReturnCode TSUrlDestroy(TSMBuffer bufp, TSMLoc offset); tsapi TS_DEPRECATED unsigned int TSHttpTxnClientIPGet(TSHttpTxn txnp); tsapi TS_DEPRECATED TSReturnCode TSHttpTxnClientRemotePortGet(TSHttpTxn txnp, int* portp); tsapi TS_DEPRECATED int TSHttpTxnClientIncomingPortGet(TSHttpTxn txnp); tsapi TS_DEPRECATED unsigned int TSHttpTxnServerIPGet(TSHttpTxn txnp); tsapi TS_DEPRECATED unsigned int TSHttpTxnNextHopIPGet(TSHttpTxn txnp); tsapi TS_DEPRECATED int TSHttpTxnNextHopPortGet(TSHttpTxn txnp); tsapi TS_DEPRECATED int TSHttpTxnMaxArgCntGet(void); tsapi TS_DEPRECATED unsigned int TSNetVConnRemoteIPGet(TSVConn vc); tsapi TS_DEPRECATED int TSNetVConnRemotePortGet(TSVConn vc); tsapi TS_DEPRECATED unsigned int TSHostLookupResultIPGet(TSHostLookupResult lookup_result); tsapi TS_DEPRECATED void TSOSIpSet(TSHttpTxn txnp, unsigned int ip); tsapi TS_DEPRECATED void TSIOBufferAppend(TSIOBuffer bufp, TSIOBufferBlock blockp); tsapi TS_DEPRECATED TSIOBufferData TSIOBufferDataCreate(void* data, int size, TSIOBufferDataFlags flags); tsapi TS_DEPRECATED TSIOBufferBlock TSIOBufferBlockCreate(TSIOBufferData datap, int size, int offset); -- 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-1198) ssl crash when certificates are missing
ssl crash when certificates are missing --- Key: TS-1198 URL: https://issues.apache.org/jira/browse/TS-1198 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.1.4 Reporter: James Peach Assignee: James Peach Fix For: 3.1.4 So, I made the mistake of upgrading ATS from trunk, without upgrading configs. And shit went to hell, with all the cores filling up my disk :). I know, it's my mistake, but perhaps there's something we can do to at least not segfault when someone has the old configs? Not a huge deal, but I'd hate for a prod box to run into this. The stack trace is below, if it makes any sense to you. -- Leif #0 0x4006e045 in SSL_CTX_callback_ctrl () from /home/server/lib/libssl.so.1.0.0 #1 0x001dc2c0 in _dl_runtime_resolve () from /lib/ld-linux.so.2 #2 0x0828c843 in SSLNetVConnection::sslStartHandShake (this=0xb52d230, event=0, err=@0x411f2e60) at SSLNetVConnection.cc:501 #3 0x0828e1b0 in SSLNetVConnection::net_read_io (this=0xb52d230, nh=0xac250d0, lthread=0xac22000) at SSLNetVConnection.cc:251 #4 0x0829589e in NetHandler::mainNetEvent (this=0xac250d0, event=5, e=0x9eb5980) at UnixNet.cc:372 #5 0x082c3774 in EThread::process_event (this=0xac22000, e=0x9eb5980, calling_code=5) at I_Continuation.h:146 #6 0x082c3f7e in EThread::execute (this=0xac22000) at UnixEThread.cc:264 #7 0x082c2b31 in spawn_thread_internal (a=0x9a6da80) at Thread.cc:88 #8 0x0037544b in start_thread () from /lib/libpthread.so.0 #9 0x002b880e in clone () from /lib/libc.so.6 -- 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-1188) http://trafficserver.apache.org/docs/trunk/admin/ts_admin_chinese.pdf is 404
http://trafficserver.apache.org/docs/trunk/admin/ts_admin_chinese.pdf is 404 Key: TS-1188 URL: https://issues.apache.org/jira/browse/TS-1188 Project: Traffic Server Issue Type: Bug Components: Web site Reporter: James Peach Assignee: Igor Galić Priority: Minor The main docs page tries to point to the Chinese admin docs at http://trafficserver.apache.org/docs/trunk/admin/ts_admin_chinese.pdf, but there's nothing there. -- 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-1162) UnixNetVConnection.cc assertion when accepting a TLS connection
UnixNetVConnection.cc assertion when accepting a TLS connection
---
Key: TS-1162
URL: https://issues.apache.org/jira/browse/TS-1162
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.1.4
Reporter: James Peach
Trunk always crashes when accepting a TLS connection:
FATAL: UnixNetVConnection.cc:801: failed assert `vio->mutex->thread_holding ==
this_ethread()`
/opt/ats/bin/traffic_server - STACK TRACE:
0 libtsutil.3.dylib 0x00010c3e7ee7 ink_fatal + 359
1 libtsutil.3.dylib 0x00010c3e6e22 _ink_assert + 66
2 traffic_server 0x00010b9e6d9a
_ZN18UnixNetVConnection11set_enabledEP3VIO + 90
3 traffic_server 0x00010b9e681d
_ZN18UnixNetVConnection8reenableEP3VIO + 93
4 traffic_server 0x00010b7bfcd6 _ZN3VIO8reenableEv +
54
5 traffic_server 0x00010b9e5cd9
_ZN18UnixNetVConnection10do_io_readEP12ContinuationxP9MIOBuffer + 297
6 traffic_server 0x00010b792611
_ZN11VConnection5do_ioEiP12ContinuationxP9MIOBufferi + 129
7 traffic_server 0x00010b9d6da9
_ZN21SSLNextProtocolAccept9mainEventEiPv + 329
8 traffic_server 0x00010b792229
_ZN12Continuation11handleEventEiPv + 121
9 traffic_server 0x00010b9e89bd
_ZN18UnixNetVConnection11acceptEventEiP5Event + 829
10 traffic_server 0x00010b792229
_ZN12Continuation11handleEventEiPv + 121
11 traffic_server 0x00010ba0905d
_ZN7EThread13process_eventEP5Eventi + 349
12 traffic_server 0x00010ba09367
_ZN7EThread7executeEv + 215
13 traffic_server 0x00010ba080ed
_ZL21spawn_thread_internalPv + 109
14 libsystem_c.dylib 0x7fff8fcb78bf _pthread_start + 335
15 libsystem_c.dylib 0x7fff8fcbab75 thread_start + 13
[Mar 22 21:58:45.009] Manager {0x7fff79b01960} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Abort trap: 6
--
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-1159) add compiler hints to debug logging
add compiler hints to debug logging --- Key: TS-1159 URL: https://issues.apache.org/jira/browse/TS-1159 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.1.4 Add compiler hints to specify that we usually don't emit diagnostic logging. -- 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-1149) pretty up automate output
pretty up automate 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] [Created] (TS-1147) deprecate records.config SSL configuration
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 Priority: Minor 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] [Created] (TS-1146) RFC 5077 TLS Session tickets
RFC 5077 TLS Session tickets Key: TS-1146 URL: https://issues.apache.org/jira/browse/TS-1146 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the machines need to have the same server ticket. See https://github.com/apache/httpd rev 967d943b93498233f0ec81a5b48706fdb6892dfd -- 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-1145) clang build fixes
clang build fixes - Key: TS-1145 URL: https://issues.apache.org/jira/browse/TS-1145 Project: Traffic Server Issue Type: Bug Components: Build Reporter: James Peach Assignee: James Peach Priority: Minor A handful of build fixes for svn versions of clang++. It's strict in slightly different ways than the current release version. -- 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-1144) fox out of tree builds
fox 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] [Created] (TS-1135) support wildcard certificates for ServerNameIndication (SNI)
support wildcard certificates for ServerNameIndication (SNI) Key: TS-1135 URL: https://issues.apache.org/jira/browse/TS-1135 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach The ServerNameIndication support added in TS-472 doesn't handle wildcard certificates. We need to add certificate parsing support to detect wildcard certificates and then (if there is not an exact match) choose the certificate with the longest wildcard match. -- 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-1134) TSNetAcceptNamedProtocol should fail if NPN is not supported
TSNetAcceptNamedProtocol should fail if NPN is not supported Key: TS-1134 URL: https://issues.apache.org/jira/browse/TS-1134 Project: Traffic Server Issue Type: Bug Components: TS API Reporter: James Peach Assignee: James Peach Priority: Minor Fix For: 3.2.0 If NPN is not supported by the OpenSSL version, TSNetAcceptNamedProtocol() should always fail so that plugins don't' get the wrong idea. -- 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-1107) dynamically scale the number of net threads
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 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] [Created] (TS-1097) online help for traffic_shell
online help for traffic_shell - Key: TS-1097 URL: https://issues.apache.org/jira/browse/TS-1097 Project: Traffic Server Issue Type: Improvement Components: Management Reporter: James Peach Priority: Minor Fix For: 3.1.2 traffic_shell should have online help for its commands -- 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-1096) readline support for traffic_shell
readline support for traffic_shell -- Key: TS-1096 URL: https://issues.apache.org/jira/browse/TS-1096 Project: Traffic Server Issue Type: Improvement Components: Management Reporter: James Peach Priority: Minor Fix For: 3.1.2 traffic_shell should use readline to support line editing and command history. -- 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-1085) traffic_shell enable command doesn't work
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 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] [Created] (TS-1084) enable compile-time format string checking
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 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] [Created] (TS-1083) initial SSL next protocol negotiation support
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 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] [Created] (TS-1082) configure always clobbers optimiser flags
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 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] [Created] (TS-1070) replace and deprecate TSFetchURL()
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
Priority: Minor
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] [Created] (TS-1066) improve ssl port documentation
improve ssl port documentation -- Key: TS-1066 URL: https://issues.apache.org/jira/browse/TS-1066 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: James Peach Priority: Minor Setting up SSL termination is documented as needing the proxy.config.ssl.server_port option. However you can do this using the proxy.config.http.server_other_ports option, but not all of the relevant attributes are documented. So I think that that: 1. The documentation of proxy.config.http.server_other_ports can be improved to document the port attribute syntax. 2. The "S<>=" attributes should be documented. 3. The interaction of proxy.config.ssl.server_port and proxy.config.http.server_other_ports should be documented. 3. The proxy.config.ssl.server_port could be deprecated in favour of server_other_ports. -- 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-1062) TSFetchUrl doesn't handle chunked encoding
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 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] [Created] (TS-1054) TSFetchUrl takes an address but does the DNS lookup anyway
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
Priority: Minor
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} DEBUG: (http_trans)
[ink_cluster_time] local: 1323923789, highest_delta: 0, cluster: 1323923789
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans) END
HttpTransact::ModifyRequest
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans) Next action
HTTP_API_READ_REQUEST_HDR; HttpTransact::StartRemapRequest
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http) [0] State
Transition: STATE_UNDEFINED -> API_READ_REQUEST_HDR
[Dec 14 20:36:29.437] Server {0x7fff7b5f9960} DEBUG: (http_trans) START
HttpTransact::StartRemapReq
[jira] [Created] (TS-1045) PATCH: add new TSFetchHdrGet API
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-1044) PATCH: Fix TSVConn{Read,Write}VIOGet in UnixNetVConnection.
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
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] [Created] (TS-1043) PATCH: teach TSFetchUrl to use the content-length to find the after_body event
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] [Created] (TS-1042) PATCH: correct debug message in FetchSM
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 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] [Created] (TS-1041) PATCH: guarantee to populate sockaddr length for TSHostLookupResultAddrGet
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] [Created] (TS-1040) PATCH: teach TSHostLookup to use const
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 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] [Created] (TS-1039) PATCH: use pcre-config to find libpcre
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
