[jira] [Created] (TS-787) disable SSLv2 by default
disable SSLv2 by default Key: TS-787 URL: https://issues.apache.org/jira/browse/TS-787 Project: Traffic Server Issue Type: Improvement Components: Configuration, SSL Affects Versions: 2.1.8 Reporter: Zhao Yongming Priority: Minor Fix For: 2.1.9 we should disable SSLv2 by default, as it is not recommended for security concern. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Plevyak updated TS-621: Attachment: ts-621-jp-3.patch This one works... but I would consider it very risky. writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached - Key: TS-621 URL: https://issues.apache.org/jira/browse/TS-621 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 2.1.5 Reporter: John Plevyak Assignee: John Plevyak Fix For: 2.1.9 Attachments: ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13034928#comment-13034928 ] Leif Hedstrom commented on TS-621: -- Yep, -3 works. This seems ok so far to me, and in line with where I was looking as well. I'll give it some more tests, but id' be great if ibrezac could test it too. writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached - Key: TS-621 URL: https://issues.apache.org/jira/browse/TS-621 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 2.1.5 Reporter: John Plevyak Assignee: John Plevyak Fix For: 2.1.9 Attachments: ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[
https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-621:
-
Comment: was deleted
(was: Took a quick look at this, nothing obvious comes to mind, yet. I did
notice the event (VC_EVENT_WRITE_COMPLETE) originates from
UnixNetVConnection.cc:476:
{code}
if (s-vio.ntodo() = 0) {
write_signal_done(VC_EVENT_WRITE_COMPLETE, nh, vc);
return;
} else if (!signalled) {
{code})
writing 0 bytes to the HTTP cache means only update the header... need a new
API: update_header_only() to allow 0 byte files to be cached
-
Key: TS-621
URL: https://issues.apache.org/jira/browse/TS-621
Project: Traffic Server
Issue Type: Improvement
Components: Cache
Affects Versions: 2.1.5
Reporter: John Plevyak
Assignee: John Plevyak
Fix For: 2.1.9
Attachments: ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.patch
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035005#comment-13035005 ] Leif Hedstrom commented on TS-621: -- I think I've found a problem on clustering here. I'm fetching e.g. curl -D - -o /dev/null -s -x cluster1.ogre.com:8080 http://www.howstuffworks.com/bearing/ So, this 301 gets cached on cluster1, I'm assuming the hashing on the URL does that. But if I fetch the same object from cluster2.ogre.com:8080, it's always a cache miss. And to make things worse, it actually forces cache1 to refresh the object as well (so it gets refetched, and updated in cache). Also, it seems that 40x's are always cached in cluster mode now, even with the proxy.config.http.negative_caching_enabled setting disabled. Neither of these problems seems to occur in the standalone cache scenario. I'll try to do some more debugging on this as well, and yes, I know we already suspect issues with clustering. John, you have any immediate ideas we should look into? :) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached - Key: TS-621 URL: https://issues.apache.org/jira/browse/TS-621 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 2.1.5 Reporter: John Plevyak Assignee: John Plevyak Fix For: 2.1.9 Attachments: ts-621-jp-1.patch, ts-621-jp-2.patch, ts-621-jp-3.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-745) Support ssd
[ https://issues.apache.org/jira/browse/TS-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035178#comment-13035178 ] mohan_zl commented on TS-745: - +1 on a branch. I am busy on preparing ts for online use these days, sorry for looking at this so late. Support ssd --- Key: TS-745 URL: https://issues.apache.org/jira/browse/TS-745 Project: Traffic Server Issue Type: New Feature Components: Cache Reporter: mohan_zl Assignee: mohan_zl Fix For: 3.1 Attachments: ssd_cache.patch A patch for supporting, not work well for a long time with --enable-debug -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-789) PURGE should purge all alternates, no matter what the request headers indicate
PURGE should purge all alternates, no matter what the request headers indicate -- Key: TS-789 URL: https://issues.apache.org/jira/browse/TS-789 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 2.1.9 If you cache e.g. a a gzip'ed version of an object only, and try to PURGE that without sending an Accept-Encoding: gzip, we will not purge the object at all (and return a 404 Not Found). This is undesirable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-789) PURGE should purge all alternates, no matter what the request headers indicate
[ https://issues.apache.org/jira/browse/TS-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-789. -- Resolution: Fixed PURGE should purge all alternates, no matter what the request headers indicate -- Key: TS-789 URL: https://issues.apache.org/jira/browse/TS-789 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 2.1.9 If you cache e.g. a a gzip'ed version of an object only, and try to PURGE that without sending an Accept-Encoding: gzip, we will not purge the object at all (and return a 404 Not Found). This is undesirable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
