[jira] Updated: (TS-463) SSL does not reuse session information
[ https://issues.apache.org/jira/browse/TS-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-463: - Component/s: SSL (was: Security) SSL does not reuse session information -- Key: TS-463 URL: https://issues.apache.org/jira/browse/TS-463 Project: Traffic Server Issue Type: New Feature Components: SSL Reporter: Leif Hedstrom Fix For: 2.3.0 SSL session resumption can reduce the load as in certain cases we can reuse the information from an already established SSL session to create a new SSL connection. We should have a ssl session cache . This was originally filed under TS-346 by Vijay, but creating a separate bug task for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-464) Chunked response with bad Content-Length header to HTTP/1.0 clent is broken
[ https://issues.apache.org/jira/browse/TS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12915490#action_12915490 ] Leif Hedstrom commented on TS-464: -- The same / similar problem occurs with HTTP/1.1 requests. Chunked response with bad Content-Length header to HTTP/1.0 clent is broken --- Key: TS-464 URL: https://issues.apache.org/jira/browse/TS-464 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Fix For: 2.3.0 A client sends an HTTP/1.0 request through ATS, which gets proxied with HTTP/1.1 to the origin. The origin (which is at fault here, but nonetheless) returns with both Content-Length: 10 Transfer-Encoding: chunked and a chunked body which is 10 bytes long. In this case, ATS should still respond with an HTTP/1.0 response, undoing the chunking, and return with an appropriate CL: header. We do everything, except set the correct Content-Length header, we simply return the erroneous CL header that the Origin provided. This is not allowed in the RFC. (Originally discovered using Coadvisor). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-464) Chunked response with bad Content-Length header to HTTP/1.0 clent is broken
[ https://issues.apache.org/jira/browse/TS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12915493#action_12915493 ] Leif Hedstrom commented on TS-464: -- And a similar problem with HTTP/1.1 POST requests, that sends both chunked encoded body and a bad CL header. It looks like we don't send the POST body at all in this case (i.e. we misinterpret the CL: header, even though it has less precedence than the chunked encoded entity). Chunked response with bad Content-Length header to HTTP/1.0 clent is broken --- Key: TS-464 URL: https://issues.apache.org/jira/browse/TS-464 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Fix For: 2.3.0 A client sends an HTTP/1.0 request through ATS, which gets proxied with HTTP/1.1 to the origin. The origin (which is at fault here, but nonetheless) returns with both Content-Length: 10 Transfer-Encoding: chunked and a chunked body which is 10 bytes long. In this case, ATS should still respond with an HTTP/1.0 response, undoing the chunking, and return with an appropriate CL: header. We do everything, except set the correct Content-Length header, we simply return the erroneous CL header that the Origin provided. This is not allowed in the RFC. (Originally discovered using Coadvisor). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-465) Need an optoin to not overwrite existing Server: header
Need an optoin to not overwrite existing Server: header --- Key: TS-465 URL: https://issues.apache.org/jira/browse/TS-465 Project: Traffic Server Issue Type: Bug Reporter: Leif Hedstrom Fix For: 2.3.0 A proxy MUST forward single valued Server response header. I suggest we extend the option CONFIG proxy.config.http.response_server_enabled INT 1 to have an additional setting, 2, which means insert the Server: header, but only if there is none in the response from the Origin server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-466) Multi-line headers are not preserved.
Multi-line headers are not preserved. - Key: TS-466 URL: https://issues.apache.org/jira/browse/TS-466 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Fix For: 2.3.0 When an origin returns a response with multi-line header(s), we merge those into one line it seems. The specs says to not touch / modify such headers, or headers we don't know about. (Originally reported by Coadvisor). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-467) Proxy shold not forward request headers that matches a Connection token
Proxy shold not forward request headers that matches a Connection token --- Key: TS-467 URL: https://issues.apache.org/jira/browse/TS-467 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Fix For: 2.3.0 If a client sends a request like X-foobar: fum Connection: ,,X-foobar,, the proxy (Traffic Server) MUST remove the header X-foobar before forwarding the request. From the RFC: HTTP/1.1 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token. and A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header MUST, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the connection-token. (Originally discovered with Coadvisor). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-318) TS doesn't guard itself well against the system time going backwards
[ https://issues.apache.org/jira/browse/TS-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-318: - Component/s: Core TS doesn't guard itself well against the system time going backwards - Key: TS-318 URL: https://issues.apache.org/jira/browse/TS-318 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Miles Libbey Fix For: 2.3.0 (was yahoo bug 2156845) Original description by Bryan Call 19 months ago at 2008-08-20 08:57 TS doesn't guard itself well against the system time going backwards (for instance in daylight savings time). Age header gets messed up and it looks like connections will timeout: Hi I ran into the following interesting behavior by accident: If the system clock changes while TS is running, TS will generate Age: header. This breaks a number of things, monitoring check being one of them. Example: From mon.corp.sp1: $ /home/libexec/check_http -w 50 -c 100 --http-version 1.0 -H coolie-status-url.yimg.com -u /magicnumbers -I .a2s.yahoo.net -vvv GET /magicnumbers HTTP/1.0 User-Agent: check_http/v1.5 (nagios-plugins 1.4.10) Connection: close Host: coolie-status-url.yimg.com http://s1.ycpi.a2s.yahoo.net:80/magicnumbers is 181 characters STATUS: HTTP/1.0 200 (OK) HEADER Cache-Control: private Date: Wed, 20 Aug 2008 06:10:03 GMT Server: YTS/1.17.8 Content-Length: 25 Content-Type: text/plain Age: 0 CONTENT 1219212603 0 80 93 On s1.ycpi.a2s.yahoo.net, changing the clock 1 hour back: $ date Tue Aug 19 23:10:32 PDT 2008 $ sudo date 08192210 Tue Aug 19 22:10:00 PDT 2008 Again, testing from the mnode - check_http times out, curl reports the Age header: $ home/libexec/check_http -w 5 -c 10 --http-version 1.0 -H coolie-status-url.yimg.com -u /magicnumbers -I s1.ycpi.a2s.yahoo.net -vvv GET /magicnumbers HTTP/1.0 User-Agent: check_http/v1.5 (nagios-plugins 1.4.10) Connection: close Host: coolie-status-url.yimg.com CRITICAL - Socket timeout after 10 seconds $ curl -D - -H 'Host: coolie-status-url.yimg.com' http://s1.ycpi.a2s.yahoo.net/magicnumbersHTTP/1.1 200 (OK) Cache-Control: private Date: Wed, 20 Aug 2008 05:11:28 GMT Server: YTS/1.17.8 Content-Type: text/plain Age: 3597 Transfer-Encoding: chunked Connection: keep-alive 1219209088 1 80 93 Restarting TS fixes it: $ restart ytrafficserver trafficserver-1.17.9: restarting ... $ home/libexec/check_http -w 5 -c 10 --http-version 1.0 -H coolie-status-url.yimg.com -u /magicnumbers -I s1.ycpi.a2s.yahoo.net -vvv GET /magicnumbers HTTP/1.0 User-Agent: check_http/v1.5 (nagios-plugins 1.4.10) Connection: close Host: coolie-status-url.yimg.com http://s1.ycpi.a2s.yahoo.net:80/magicnumbers is 181 characters STATUS: HTTP/1.0 200 (OK) HEADER Cache-Control: private Date: Wed, 20 Aug 2008 05:16:01 GMT Server: YTS/1.17.9 Content-Length: 25 Content-Type: text/plain Age: 0 CONTENT 1219209361 3 80 93 HTTP OK HTTP/1.0 200 (OK) - 181 bytes in 0.268 seconds |time=0.267525 size=181 Rolling the clock FORWARD does not cause any impact. -- Ivan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-301) Change strerror() to strerror_r()
[ https://issues.apache.org/jira/browse/TS-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-301: - Component/s: Cleanup Change strerror() to strerror_r() - Key: TS-301 URL: https://issues.apache.org/jira/browse/TS-301 Project: Traffic Server Issue Type: Improvement Components: Cleanup Reporter: Miles Libbey Fix For: 2.3.0 (moving from yahoo bug 520229 to Jira) In a few places, we use strerror() instead of strerror_r(). The latter is obviously much better in a threaded application like this. Comment 1 by Vladimir Legalov 3 years ago at 2006-08-15 09:52:07 Since strerror_r changes errno, all changes must be done very carefully with counting such unexpected change inside calling code. Please see man for more details. Comment 2 by Ryan Troll 3 years ago at 2006-08-15 13:12:12 Good catch. You're right, differences like this have to be accounted for. Does TS actually use the global errno? I didn't think it's use was threadsafe. It's surprising that strerror_r set's errno on Linux -- it doesn't do that on FreeBSD. And it's not like it sets the value to anything besides EINVAL... -R Comment 3 by Vladimir Legalov 3 years ago at 2006-08-15 14:16:42 TS is using strerror everywhere and in 99% cases it is not thread-safe (except fatal error case). It works well only because of very low probability of error conditions when strerror is called. -v:) Comment 4 by Leif Hedstrom 3 years ago at 2006-08-16 07:53:42 But this is only a problem if sterror_r() is called with an invalid errnum, right? What are the odds of that happening? We could maybe produce an error in the log if that happens, because if it does, I think it'd indicate a problem somewhere in our code. Comment 5 by Vladimir Legalov 3 years ago at 2006-11-01 14:02:07 strerror_r replacement should be done only per module base. Since strerror_r is changing errno it is not safe to do such replacement 'blindly'. I will keep this bug 'open' just as reminder only. Comment 6 by Leif Hedstrom 3 years ago at 2006-11-01 15:18:26 I still don't understand this, strerror and sterror_r has the same logic/behaviour. Both functions will modify errno if the call fails, if not, leave it alone. What am I missing? Comment 7 by Vladimir Legalov 3 years ago at 2006-11-01 16:37:25 The strerror_r() function could potentially change errno on failure. It is almost impossible situation in Linux since strerror_r blindly ignores any incorrect arguments and calls strerror. However, I think we should not count on this Linux specific feature. That's why we should check each strerror usage case and wrapping code for 'errno' validition. If wrapping code is not requiring original errno after strerror call we can do strerror_r replacement blindly. Comment 8 by Leif Hedstrom 3 years ago at 2006-11-01 16:43:19 Right, but that's the exact same behaviour as sterror, from the man page: The value of errno is not changed for a successful call, and is set to a nonzero value upon error. As far as I can tell, the behaviour is identical for both calls, so changing to strerror_r() would have no different side effects from strerror(). Besides, I think the odds of triggering a change to errno is from calling either of these functions is very, very small (and would indicate horrible coding on our part). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-407) traffic_server not using proxy.config.syslog_facility
[
https://issues.apache.org/jira/browse/TS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-407:
-
Component/s: Core
traffic_server not using proxy.config.syslog_facility
-
Key: TS-407
URL: https://issues.apache.org/jira/browse/TS-407
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Fix For: 2.3.0
We have this code in Main.cc:
static int syslog_facility = LOG_DAEMON;
// static void syslog_log_configure()
//
// Reads the syslog configuration variable
// and sets the global integer for the
// facility and calls open log with the
// new facility
//
static void
syslog_log_configure()
{
char *facility_str = NULL;
int facility;
TS_ReadConfigStringAlloc(facility_str, proxy.config.syslog_facility);
if (facility_str == NULL || (facility =
facility_string_to_int(facility_str)) 0) {
syslog(LOG_WARNING, Bad or missing syslog facility. Defaulting to
LOG_DAEMON);
} else {
syslog_facility = facility;
closelog();
openlog(traffic_server, LOG_PID | LOG_NDELAY | LOG_NOWAIT, facility);
}
}
But as far as I can tell, we never use syslog_facility.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-307) Possible performance problem: DNS lookup continuation is using first Network ethread for all operations
[ https://issues.apache.org/jira/browse/TS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-307: - Component/s: DNS Possible performance problem: DNS lookup continuation is using first Network ethread for all operations --- Key: TS-307 URL: https://issues.apache.org/jira/browse/TS-307 Project: Traffic Server Issue Type: Improvement Components: DNS Reporter: Miles Libbey Priority: Minor Fix For: 2.3.0 (from yahoo bug 989959) Original description by Vladimir Legalov 3 years ago at 2006-12-18 11:57 All DNS lookup operations are executing on the first Network thread. Since each Network thread is already responsible for NetAccept NetHandler continuation processing, DNS processing can cause extra CPU usage and additional delays for this particular thread. It make sense to extract DNS processing as absolutely independent thread (ethread) to avoid possible performance problem related to DNS lookups. Such performance problem can be visible only in no caching mode with very high rate of OS requests. Additional performance testing is required to clarify visibility of this problem. (It looks like htop is not an appropriate tool to catch precise CPU usage per thread.) Comment 1 by Leif Hedstrom 3 years ago at 2006-12-26 13:41:10 I think it's highly unlikely that DNS will ever become a bottleneck. Even under extreme cases, like say 300 Origin Servers all with a TTL of 5 minutes (we rarely have anything shorter), we're looking at one DNS lookup per second (assuming there are no cache hits, as pointed out already). I'm closing this bug until we have some real evidence that DNS lookups is ever going to be any sort of bottleneck. Comment 2 by Vladimir Legalov 3 years ago at 2006-12-26 20:31:17 I don't understand why we should not keep this RFE open. I would prefer to keep DNS lookup code as separate thread not because of a huge performance impact but because the DNS lookup continuation is activated every 11 milliseconds (just to verify the status of the 32 UDP sockets) even if we don't need to do perform a DNS lookup. One more thing - this continuation is impacting eThread scheduling for first NetHandler continuation. I am 100% sure that all NetHandler continuations must be symmetrical/equal and have similar scheduling. I would prefer to reopen this RFE. Comment 3 by Ryan Troll 3 years ago at 2006-12-27 06:47:47 Reopened, with *very low* priority. I'd recommend waiting until the bigger items are done before tackling this. Yes, we may be spending time in DNS in this thread when we don't need to; and maybe a single DNS thread is the right answer. Or maybe modifying the DNS code to not bother with DNS continuations unless there are outstanding DNS requests makes more sense. However, I'd wait on this until we have time to go back and tune it. It may squeeze a little more performance out of the stack, but I suspect there are bigger wins to be gained through enhancements that are being actively requested by properties; or through enhancements we've already identified. It makes sense to keep this open so we don't forget about it. Hopefully we'll get to it later this year. Comment 4 by Leif Hedstrom 3 years ago at 2006-12-27 07:42:47 The reason I closed this bug was that the bug report indicated that this would be a problem under heavy load, with no caching. I don't believe that to be the case. In best case DNS lookups will be of O(1) complexity, and worst case it'd be O(n), where n is the number of origin servers. In either of those case, performing the actualy DNS lookups will be negligible as far as CPU consumption is concerned. However, with the comment from Vlad, it seems the concern is about wasting time on the DNS continuation, which I agree might be worth investigating. But I'd also like to see some benchmarks on how much this does affect us today. I'm not sure exactly how to test this. Vlad, is it possible to increase the timer for the DNS continuation to get scheduled, e.g. have it run every 1 second? Then we could easily benchmark what effect that has on performance. Comment 5 by Vladimir Legalov 3 years ago at 2006-12-27 19:09:23 The existence of this RFE does not mean that it will be taken on our development table immediately. It is a reminder only. As I already mentioned in the initial comments for this RFE: Additional performance testing is required to clarify visibility of this problem. We have plenty of similar RFE's by priority and severity, which are not in active development. I was sure that P4 is
[jira] Updated: (TS-232) Startup script should use lsb when available
[ https://issues.apache.org/jira/browse/TS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-232: - Component/s: Portability Startup script should use lsb when available -- Key: TS-232 URL: https://issues.apache.org/jira/browse/TS-232 Project: Traffic Server Issue Type: Improvement Components: Portability Reporter: Leif Hedstrom Priority: Minor Fix For: 2.3.0 I don't know how much of a change this would be, but I think we should change the startup script so that for all distros that have lsb support, we should use that for the start/stop/status etc. functionality. This would take precedence over special distros functionality, and could hopefully clean out some code too. We need to leave the existing pieces where there are distros that do not have modern lsb capabilities. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-465) Need an optoin to not overwrite existing Server: header
[ https://issues.apache.org/jira/browse/TS-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-465: - Component/s: HTTP Need an optoin to not overwrite existing Server: header --- Key: TS-465 URL: https://issues.apache.org/jira/browse/TS-465 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Fix For: 2.3.0 A proxy MUST forward single valued Server response header. I suggest we extend the option CONFIG proxy.config.http.response_server_enabled INT 1 to have an additional setting, 2, which means insert the Server: header, but only if there is none in the response from the Origin server. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-312) add option to always share keep-alive connections to the origin server
[ https://issues.apache.org/jira/browse/TS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-312: - Component/s: Network add option to always share keep-alive connections to the origin server --- Key: TS-312 URL: https://issues.apache.org/jira/browse/TS-312 Project: Traffic Server Issue Type: Improvement Components: Network Reporter: Miles Libbey Priority: Minor Fix For: 2.3.0 (was yahoo bug 1411758) Original description by Bryan Call (bcall) 2 years ago at 2007-08-08 13:35 Leif and I were talking about extending the meaning of proxy.config.http.share_server_session for reusing keep-alive connections from the TS server and the origin server, for separate clients attached to TS. You can read more about this in [BUG 1162233]. The configuration options should be: so lets add more options to share_server_session? E.g. 0 - Never share/reuse connections 1 - Share/reuse connections if max_connections is set (default) 2 - Always try to share-reuse connections option 1 will give the behavior we currently have and 2 will always try to share the keep-alive connections to the origin servers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-382) socket option cleanup (and bug fixes)
[ https://issues.apache.org/jira/browse/TS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-382: - Component/s: Network socket option cleanup (and bug fixes) --- Key: TS-382 URL: https://issues.apache.org/jira/browse/TS-382 Project: Traffic Server Issue Type: Bug Components: Network Reporter: Leif Hedstrom Fix For: 2.3.0 This is a bug moved from Y! Bugzilla, I'm posting the original bug description and a few comments separately. Note that the bug description is fairly limited, but while looking at this code, I noticed a lot of oddities with the socket option support (lots of hardcoded stuff, and most of it is not configurable). Note that the original bug should have been fixed already in Apache TS, but the other comments are still applicable. From Bugzilla (posted by Leif): We have two socket option config options in records.config: proxy.config.net.sock_option_flag_in proxy.config.net.sock_option_flag_out With accept thread enabled, at least the _in option isn't honored. There are possibly other cases in UnixNetAccept.cc that we don't honor these flags either. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-304) TS Doesn't treat badly formatted Expires as stale
[ https://issues.apache.org/jira/browse/TS-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-304: - Component/s: HTTP TS Doesn't treat badly formatted Expires as stale - Key: TS-304 URL: https://issues.apache.org/jira/browse/TS-304 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Miles Libbey Priority: Minor Fix For: 2.3.0 (moved from yahoo bug 784579) Original description by Vladimir Legalov 3 years ago at 2006-08-23 21:27 Ill-formatted Expires header values should be treated as being in the past, so that any mistakes will have the appropriate effect. TS treats these as if the Expires header wasn't there, assigning a heuristic freshness to the responses. The safe thing to do would be to consider it stale. From RFC2616: HTTP/1.1 clients and caches MUST treat other invalid date formats, especially including the value 0, as in the past (i.e., already expired). Comment 1 by Leif Hedstrom 3 years ago at 2006-08-24 07:18:24 I don't think this is particularly critical for us, since we have control of all Origin servers. Ryan's Origin verification tool also warns about bad Expire headers. Not saying we shouldn't fix this, but it's low priority IMO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-315) Add switch to disable config file generation/runtime behavior changing
[ https://issues.apache.org/jira/browse/TS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-315: - Component/s: Configuration Add switch to disable config file generation/runtime behavior changing -- Key: TS-315 URL: https://issues.apache.org/jira/browse/TS-315 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Miles Libbey Priority: Minor Fix For: 2.3.0 (was yahoo bug 1863676) Original description by Michael S. Fischer 2 years ago at 2008-04-09 09:52 In production, in order to improve site stability, it is imperative that TS never accidentally overwrite its own configuration files. For this reason, we'd like to request a switch be added to TS, preferably via the command line, that disables all automatic configuration file generation or other runtime behavioral changes initiated by any form of IPC other than 'traffic_line -x' (including the web interface, etc.) Comment 1 by Bjornar Sandvik 2 years ago at 2008-04-09 09:57:17 A very crucial request, in my opinion. If TS needs to be able to read command-line config changes on the fly, these changes should be stored in another config file (for example remap.config.local instead of remap.config). We have a patch config package that overwrites 4 of the config files under /home/conf/ts/, and with all packages we'd like to think that the content of these files can't change outside our control. Comment 2 by Bryan Call 2 years ago at 2008-04-09 11:02:46 traffic_line -x doesn't modify the configuration, it reloads the configuration files. If we want to have an option for this it would be good to have it as an option configuration file (CONFIG proxy.config.write_protect INT 1). It would be an equivalent of write protecting floppies (ahh the memories)... Comment 3 by Michael S. Fischer 2 years ago at 2008-04-09 11:09:09 I don't think it would be a good idea to have this in the configuration file, as it would introduce a chicken/egg problem. Comment 4 by Leif Hedstrom 19 months ago at 2008-08-27 12:43:17 So I'm not 100% positive that this isn't just a bad interaction. Now, it's only triggered when trafficserver is running, but usually what ends up happening is that we get a records.config which looks like it's the default config that comes with the trafficserver package. It's possible it's all one and the same issue, or we might have two issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-316) Add a limit to the number of requests through a single KeepAlive connection
[ https://issues.apache.org/jira/browse/TS-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-316: - Component/s: Network Add a limit to the number of requests through a single KeepAlive connection Key: TS-316 URL: https://issues.apache.org/jira/browse/TS-316 Project: Traffic Server Issue Type: Improvement Components: Network Reporter: Miles Libbey Priority: Minor Fix For: 2.3.0 (was yahoo bug 1953368) Original description by Daniel Weaver 22 months ago at 2008-05-22 14:50 This is a request to support a mechanism equivalent to Apache's MaxKeepAliveRequests directive. http://httpd.apache.org/docs/1.3/mod/core.html#maxkeepaliverequests Basically, after the specified number of requests come through, a Connection: close header is sent back to the client to break the connection. This is useful because eternal Keep-Alive essentially thwarts load balancers, and can result in very uneven traffic over time (especially when restarting a TS -- all connections are broken when it shuts down, and then when it restarts it gets no new connections, because all the clients have Keep-Alive sessions with the other TS's that were behind the vip). This conversation started in bug 1950760; see it for additional context. Sherpa may experiment with inserting Connection: close headers randomly in its response plugin in the meantime. Comment 1 by Chuck Neerdaels 22 months ago at 2008-05-22 15:11:32 If it's added to the general TS path it'll break stuff. For instance pipelining - if a client shoots 6 requests and you do a shutdown after they get a response for 3, they have to unwind and reissue the requests. Yes, clients could be written to deal with this, but there's a general assumption that if you accepted and read the request, you intend to answer it - barring something catastrophic. The 1.1 spec is pretty ambiguous here. Closing connections when there's a timeout generally flies, but inserting one midstream while under load is going to backfire. Proxies just don't do that - even though servers and clients can. chuck Comment 2 by Daniel Weaver 22 months ago at 2008-05-22 15:56:14 Yeah... not a lot of commentary out there on the interaction between pipelining and connection closing. I did find this article that emphasizes, Servers must therefore close each half of the connection independently. http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html#After_Tuning -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TS-356) Switch code base to C99 ?
[ https://issues.apache.org/jira/browse/TS-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-356. -- Resolution: Won't Fix Switch code base to C99 ? - Key: TS-356 URL: https://issues.apache.org/jira/browse/TS-356 Project: Traffic Server Issue Type: Improvement Reporter: Leif Hedstrom Priority: Minor Fix For: 2.3.0 This is a placeholder bug for tracking changes we should do to make the code C99 compatible. Note that C99 is not fully supported by many (most?) compilers, so we have to be a little bit careful with what we use. Please attach to this bug for areas / code changes that we should consider. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-449) Split RecordsConfig.cc into modules
[ https://issues.apache.org/jira/browse/TS-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-449: - Component/s: Configuration Split RecordsConfig.cc into modules - Key: TS-449 URL: https://issues.apache.org/jira/browse/TS-449 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Leif Hedstrom Priority: Minor Fix For: 2.3.0 To modularize configurations, we ought to split proxy/mgmt2/RecordsConfig.cc into each module. This is/was partially done, albeit very incomplete, for iocore. What I'd suggest we do is something like 1) Create a RecordsConfig.cc for each module that has configurations. This should allow for the same capabilities as the old RecordsConfig.cc, and should use the same APIs / format for all modules. 2) Once migrated over to a module specific RecordsConfig.cc, eliminate it from the old proxy/mgmt2/RecordsConfig.cc. This allows for per-module migration over to the new layout. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-317) Need a way for remap plugins to modify Host: headers
[ https://issues.apache.org/jira/browse/TS-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-317: - Component/s: Remap API Need a way for remap plugins to modify Host: headers - Key: TS-317 URL: https://issues.apache.org/jira/browse/TS-317 Project: Traffic Server Issue Type: Improvement Components: Remap API Reporter: Miles Libbey Priority: Minor Fix For: 2.99 (was yahoo bug 2148838) Original description by Leif Hedstrom 20 months ago at 2008-08-17 14:03 We need a way for a plugin to set the host field to one value (X), but force the Host: header to be a different value (Y). This is similar (but not the same) as keeping Host: headers pristine during remap rules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-410) Should regression code be compile time optional?
[ https://issues.apache.org/jira/browse/TS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-410: - Component/s: Build Should regression code be compile time optional? Key: TS-410 URL: https://issues.apache.org/jira/browse/TS-410 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: Leif Hedstrom Priority: Minor Fix For: 2.3.0 Would it make sense to make the compilation (and inclusion) of the regression tests compile time (configure time) optional? Default would be off, but could be enabled with something like --with-regression-tests -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-309) Report OS Errors in Header
[ https://issues.apache.org/jira/browse/TS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-309: - Component/s: HTTP Report OS Errors in Header -- Key: TS-309 URL: https://issues.apache.org/jira/browse/TS-309 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Miles Libbey Fix For: 2.3.0 (from yahoo bug 1021194) Original description by Ryan Troll 3 years ago at 2007-01-17 13:20 Cleaning out my mailbox; and I didn't want this to disappear. Back on 12/12 Scott asked for a way to look at a YTS response and differentiate between a TS error, and an Origin server error. I *think* the general idea is that, whenever the origin server returns an error; we return it to the client. However, if there's a problem contacting the origin server, we should return the appropriate HTTP response: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5 including 500 Internal Server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout 505 HTTP Version Not Supported and specify what Origin Server triggered the error in the Warning header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.46 I think we could define our own warn code and use it specify the origin server host (by name and IP): 504 Gateway Timeout Date: Wed, 17 Jan 2007 21:17:25 GMT Warning: 599 l1.ycs.s1s.yahoo.com:80 OS: us.yimg.com [66.218.71.81] But that's just a thought. Maybe mnot has a good suggestion -- he pointed us towards the Warning: header, and may know of good examples of it's use in the real world. Comment 1 by Chuck Neerdaels 3 years ago at 2007-01-18 16:33:15 There's a pretty cool feature in TS, where it embeds codes into a Via header (if those are turned on) where someone looking at the headers can see whether it was a cache hit, an IMS hit, etc. As it moves through the state machine, it appends characters to the string - and in the reply you get something like [uN l oS f pS eN] which would translate to a user issuing a no-cache pragma, that resulted in an origin server fetch, which was served without error. It's pretty useful, so we might want to consider enabling this. There's a cheat sheet at /dev/traffic/trunk/proxy/http2/README.via chuck -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-305) sigTERM should cause a user-friendly shutdown
[ https://issues.apache.org/jira/browse/TS-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-305: - Component/s: Core sigTERM should cause a user-friendly shutdown - Key: TS-305 URL: https://issues.apache.org/jira/browse/TS-305 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Miles Libbey Priority: Minor Fix For: 2.3.0 (from yahoo bug 848837) Original description by Scott Manjourides 3 years ago at 2006-10-16 15:48 On Monday 16 October 2006 03:01 pm, Ryan Troll wrote: Open a RFE asking to have sigTERM cause a user-friendly shutdown? Something like: - immediately set all KeepAlive timeout values to 5 seconds :: Optional, but could make shutdown faster than leaving at :: whatever the property specified. - no longer accept new connections - process exits when all existing connections close -R -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-375) Expose MUTEX_RETRY_DELAY HRTIME_MSECONDS as a configurable option?
[ https://issues.apache.org/jira/browse/TS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-375: - Component/s: InkAPI Expose MUTEX_RETRY_DELAY HRTIME_MSECONDS as a configurable option? -- Key: TS-375 URL: https://issues.apache.org/jira/browse/TS-375 Project: Traffic Server Issue Type: New Feature Components: InkAPI Reporter: Leif Hedstrom Priority: Minor Fix For: 2.3.0 Would it make sense to expose MUTEX_RETRY_DELAY HRTIME_MSECONDS as a configurable option? It would allow a very skilled user to tweak the lock rescheduling to fit her application, HW and load patterns optimally. This would be a stop-gap solution for some situations, until we can reduce / eliminate some of the rescheduling that happens (and it would be very application specific). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-303) plugin idea: - a config option to transform a 'no-cache' directive into a validation 'if-modified-since' request
[ https://issues.apache.org/jira/browse/TS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-303: - Component/s: Plugins plugin idea: - a config option to transform a 'no-cache' directive into a validation 'if-modified-since' request Key: TS-303 URL: https://issues.apache.org/jira/browse/TS-303 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Miles Libbey Priority: Minor Fix For: 2.4.0 (moved from yahoo bug 633221) Original description by John Allspaw 4 years ago at 2006-04-17 11:04 This does disobey some of the HTTP specification, but it is a great performance win when you're totally sure that something hasn't/can't be changed. Squid has this, and this is ideally how it goes: When set, this option would make TrafficServer transform a request with a no-cache directive into a validation (If-Modified-Since) request. In other words, TrafficServer ads an If-Modified-Since header to the request before forwarding it on. Note that this would only work for objects that have a Last-Modified timestamp. Comment 1 by Mark Nottingham 4 years ago at 2006-04-17 13:14:30 They other thing you could (optionally, depending on config?) do is to ignore cache-control request headers all together. If you're confident of the cache's correctness, this doesn't allow the browser to force a round trip back to your origin server (which could be an attack vector). It really doesn't break HTTP if you're acting as a gateway; they're allowed to do pretty much what they want. Comment 2 by John Allspaw 4 years ago at 2006-04-17 13:20:33 Mark: yeah, TS does already have the option to completely ignore cache-control headers, confirmed by Leif. I've generally thought that having the transform into IMS just adds a slight amount of flexibility than the baby/bathwater if totally ignoring. :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-313) DNS and resolvers improvements
[ https://issues.apache.org/jira/browse/TS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-313: - Component/s: DNS DNS and resolvers improvements -- Key: TS-313 URL: https://issues.apache.org/jira/browse/TS-313 Project: Traffic Server Issue Type: Improvement Components: DNS Reporter: Miles Libbey Assignee: Leif Hedstrom Priority: Minor Fix For: 2.1.4 Attachments: TS-313-DNS_round_robin_and_failover_v1.patch, TS-313-DNS_round_robin_and_failover_v2.patch, TS-313-Interim.patch (was yahoo bug 1542263) Original description by Leif Hedstrom 2 years ago at 2007-10-16 17:00 There are two options to configure/manage how TS finds resolvers via records.config: CONFIG proxy.config.dns.round_robin_nameservers INT 0 CONFIG proxy.config.dns.nameservers STRING NULL Without these set, TS will simply parse /etc/resolv.conf, to find nameserver/resolver entries. This is fine. However, there are a few things that are broken or could be improved with the two options above: 1) If you want to do round robin over your resolvers, you must also explicitly define the set of servers in the dns.nameservers config. There is no way to have it round robin over the default resolvers from /etc/resolv.conf. 2) You can not set an explicit set of dns.nameservers, without also making them be used in a round robin fashion. This is highly undesirable for instance if you want to use a local resolver first (listening on 127.0.0.1), but fall back to a set of regular resolvers. 3) Once listing explicit dns.nameservers, there is no way to have it also add the implicit resolvers from /etc/resolv.conf. It'd be very useful if you could include an external filename as part of the nameservers list, e.g. 127.0.0.1,/etc/resolv.conf I'd suggest we separate the intertwined relationship between the two options, which would solve issues #1 and #2. As a bonus feature, we should be able to either implement the flexibility of #3, or at least make it possible (via a new config option) to include /etc/resolv.conf resolvers even when dns.nameservers is set. Marking this as an RFE, as it's not exactly a bug, but it's still somewhat critical for us to support this properly. Comment 1 by Yung-Zen Lai 21 months ago at 2008-07-09 18:56:24 Per issue #2, proxy.config.dns.nameservers config currently only works while setting CONFIG proxy.config.dns.round_robin_nameservers INT 1. Even only one dns.nameservers is set. It seems not that make sense. ^^a -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-310) modifying global_user_agent_header requires restart
[ https://issues.apache.org/jira/browse/TS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-310: - Component/s: Configuration modifying global_user_agent_header requires restart --- Key: TS-310 URL: https://issues.apache.org/jira/browse/TS-310 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Miles Libbey Priority: Minor Fix For: 2.3.0 (was y bug 1389544) Original description by Leif Hedstrom2 years ago at 2007-07-26 16:38 I don't know why, or if it's intentional, but modifying the config for proxy.config.http.global_user_agent_header requires a server restart. This is obviously not a huge problem, but inconsistent and confusing. I can't think of any reasons why we shouldn't support dynamically rereading this particular configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-468) We should respond with a 417 if we cannot meet an expectation
We should respond with a 417 if we cannot meet an expectation - Key: TS-468 URL: https://issues.apache.org/jira/browse/TS-468 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom If the client sends an Expect: header that we cannot meet, we should return a 417 error. E.g. Expect: expect=params since we can't meet this expectation, we should return a 417, but instead we forward this to the origin, and return with whatever it responds with. (Originally found using Coadvisor). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-469) A PUT request should invalidate a previously cached object with the same URI
[ https://issues.apache.org/jira/browse/TS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-469: - Affects Version/s: 2.3.0 A PUT request should invalidate a previously cached object with the same URI Key: TS-469 URL: https://issues.apache.org/jira/browse/TS-469 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 2.3.0 Reporter: Leif Hedstrom If the client first fetches an object with GET, and TS caches it, a subsequent PUT request for the same URL should invalidate the cached object. (Originally discovered with Coadvisor). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-469) A PUT request should invalidate a previously cached object with the same URI
A PUT request should invalidate a previously cached object with the same URI Key: TS-469 URL: https://issues.apache.org/jira/browse/TS-469 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom If the client first fetches an object with GET, and TS caches it, a subsequent PUT request for the same URL should invalidate the cached object. (Originally discovered with Coadvisor). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-469) A PUT request should invalidate a previously cached object with the same URI
[ https://issues.apache.org/jira/browse/TS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-469: - The same with a POST request. A PUT request should invalidate a previously cached object with the same URI Key: TS-469 URL: https://issues.apache.org/jira/browse/TS-469 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 2.3.0 Reporter: Leif Hedstrom If the client first fetches an object with GET, and TS caches it, a subsequent PUT request for the same URL should invalidate the cached object. (Originally discovered with Coadvisor). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-470) Age: headers INT_MAX should be capped to 2^31
Age: headers INT_MAX should be capped to 2^31 --- Key: TS-470 URL: https://issues.apache.org/jira/browse/TS-470 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Fix For: 2.3.0 We should cap Age: headers with a value 2^31 to 2^31. (Discovered using Coadvisor). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-470) Age: headers INT_MAX should be capped to 2^31
[ https://issues.apache.org/jira/browse/TS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12915598#action_12915598 ] Leif Hedstrom commented on TS-470: -- Test this with Age: headers of Age: 2147483647 and Age: 2147483648 Age: headers INT_MAX should be capped to 2^31 --- Key: TS-470 URL: https://issues.apache.org/jira/browse/TS-470 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Fix For: 2.3.0 We should cap Age: headers with a value 2^31 to 2^31. (Discovered using Coadvisor). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TS-469) A PUT request should invalidate a previously cached object with the same URI
[ https://issues.apache.org/jira/browse/TS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12915600#action_12915600 ] Leif Hedstrom commented on TS-469: -- Update: This is a problem with PUT/POST when the response from the origin is a 201, and there is a Location: header. We then must also invalidate any cached object for the URL which the Location header refers to. A PUT request should invalidate a previously cached object with the same URI Key: TS-469 URL: https://issues.apache.org/jira/browse/TS-469 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 2.3.0 Reporter: Leif Hedstrom If the client first fetches an object with GET, and TS caches it, a subsequent PUT request for the same URL should invalidate the cached object. (Originally discovered with Coadvisor). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-471) We don't set Content-Length: header properly for 2^31 values
We don't set Content-Length: header properly for 2^31 values
Key: TS-471
URL: https://issues.apache.org/jira/browse/TS-471
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Leif Hedstrom
Fix For: 2.1.4
If the body is a chunked encoded response, and we convert it to have a
content-length header, I believe we don't produce a correct value for the CL:
header. The code is
inline void
MIMEHdr::set_content_length(int64 value)
{
value_set_int(MIME_FIELD_CONTENT_LENGTH, MIME_LEN_CONTENT_LENGTH, value);
}
but I'm fairly certain we want the equivalent of value_set_int64() (which
doesn't exist). Marking this one for v2.1.4, since it most likely doesn't work
properly for 2^31 chunked encoded objects.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-470) Age: headers INT_MAX should be capped to 2^31
[ https://issues.apache.org/jira/browse/TS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-470: - Attachment: TS-470.diff Proposed patch (v1). Age: headers INT_MAX should be capped to 2^31 --- Key: TS-470 URL: https://issues.apache.org/jira/browse/TS-470 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Fix For: 2.3.0 Attachments: TS-470.diff We should cap Age: headers with a value 2^31 to 2^31. (Discovered using Coadvisor). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
