[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978057#comment-13978057
]
Faysal Banna commented on TS-2564:
--
Hi Guys
i don't know if this is related to the same issue here or different one.
after upgrading from 4.2.0 to 5.0.0 and applying the patches in here and
enabling rfc5861.
i start getting this
FATAL: InkAPI.cc:2677: failed assert `sdk_sanity_check_mbuffer(bufp) ==
TS_SUCCESS`
/usr/local/bin/traffic_server - STACK TRACE:
/usr/local/lib/libtsutil.so.5(+0x1e8b7)[0x2b48629c28b7]
/usr/local/lib/libtsutil.so.5(+0x1d86f)[0x2b48629c186f]
/usr/local/bin/traffic_server(TSMimeHdrFieldFind+0x2f)[0x4b36ef]
/usr/local/libexec/trafficserver/rfc5861.so(+0x301a)[0x2b486daec01a]
/usr/local/bin/traffic_server(EThread::process_event(Event*,
int)+0x170)[0x70d8e0]
/usr/local/bin/traffic_server(EThread::execute()+0x793)[0x70e4b3]
/usr/local/bin/traffic_server[0x70d1fa]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x2b4863ddaf6e]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b4864b0c9cd]
much regards
> Segmentation fault in 4.2.0-rc0
> ---
>
> Key: TS-2564
> URL: https://issues.apache.org/jira/browse/TS-2564
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Phil Sorber
>Priority: Blocker
> Labels: crash
> Fix For: 4.2.1, 5.0.0
>
> Attachments: ts-2564-B.diff, ts-2564.diff
>
>
> Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
> 4.2.0-rc0:
> {code}
> (gdb) bt
> #0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
> field=, detach_all_dups=false) at MIME.cc:469
> #1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=,
> detach_all_dups=false) at MIME.cc:1538
> #2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
> mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups= out>) at MIME.cc:1586
> #3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
> response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
> #4 field_delete (cached_header=0x2acde002fa40,
> response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
> #5 HttpTransact::merge_response_header_with_cached_header
> (cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
> HttpTransact.cc:4914
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978131#comment-13978131
]
Faysal Banna commented on TS-2564:
--
I have to admit also
the patches provided here didn't work on 5.0.0 as i still get
/usr/local/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0)[0x2b004c824bb0]
/usr/local/bin/traffic_server[0x6189d0]
/usr/local/bin/traffic_server(mime_field_value_get_comma_list(MIMEField*,
StrList*)+0x8e)[0x61d9de]
/usr/local/bin/traffic_server(HttpTransactCache::CalcVariability(CacheLookupHttpConfig*,
HTTPHdr*, HTTPHdr*, HTTPHdr*)+0x1cc)[0x5b85dc]
/usr/local/bin/traffic_server(HttpTransactCache::calculate_quality_of_match(CacheLookupHttpConfig*,
HTTPHdr*, HTTPHdr*, HTTPHdr*)+0x129)[0x5b8b89]
/usr/local/bin/traffic_server(HttpTransactCache::SelectFromAlternates(CacheHTTPInfoVector*,
HTTPHdr*, CacheLookupHttpConfig*)+0x116)[0x5b9936]
/usr/local/bin/traffic_server(CacheVC::openReadStartHead(int,
Event*)+0x12cd)[0x6b39cd]
/usr/local/bin/traffic_server(CacheVC::handleReadDone(int,
Event*)+0x1c6)[0x690486]
/usr/local/bin/traffic_server(AIOCallbackInternal::io_complete(int,
void*)+0x33)[0x649813]
/usr/local/bin/traffic_server(EThread::process_event(Event*,
int)+0x170)[0x70d8e0]
/usr/local/bin/traffic_server(EThread::execute()+0x793)[0x70e4b3]
/usr/local/bin/traffic_server[0x70d1fa]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x2b004c81cf6e]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b004d54e9cd]
[E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local'
much regards
> Segmentation fault in 4.2.0-rc0
> ---
>
> Key: TS-2564
> URL: https://issues.apache.org/jira/browse/TS-2564
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Phil Sorber
>Priority: Blocker
> Labels: crash
> Fix For: 4.2.1, 5.0.0
>
> Attachments: ts-2564-B.diff, ts-2564.diff
>
>
> Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
> 4.2.0-rc0:
> {code}
> (gdb) bt
> #0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
> field=, detach_all_dups=false) at MIME.cc:469
> #1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=,
> detach_all_dups=false) at MIME.cc:1538
> #2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
> mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups= out>) at MIME.cc:1586
> #3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
> response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
> #4 field_delete (cached_header=0x2acde002fa40,
> response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
> #5 HttpTransact::merge_response_header_with_cached_header
> (cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
> HttpTransact.cc:4914
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2739) ATS doesn't send back Transfer-Encoding when client keep-alive is turned off
Wei Sun created TS-2739: --- Summary: ATS doesn't send back Transfer-Encoding when client keep-alive is turned off Key: TS-2739 URL: https://issues.apache.org/jira/browse/TS-2739 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Wei Sun When client is turned off and origin server responds 'Transfer-Encoding: chunked', ats doesn't send back this header which is required by some clients. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2739) ATS doesn't send back Transfer-Encoding when client keep-alive is turned off
[ https://issues.apache.org/jira/browse/TS-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2739: Fix Version/s: 5.0.0 > ATS doesn't send back Transfer-Encoding when client keep-alive is turned off > > > Key: TS-2739 > URL: https://issues.apache.org/jira/browse/TS-2739 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Wei Sun > Fix For: 5.0.0 > > > When client is turned off and origin server responds 'Transfer-Encoding: > chunked', ats doesn't send back this header which is required by some clients. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2739) ATS doesn't send back Transfer-Encoding when client keep-alive is turned off
[ https://issues.apache.org/jira/browse/TS-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun reassigned TS-2739: --- Assignee: Wei Sun > ATS doesn't send back Transfer-Encoding when client keep-alive is turned off > > > Key: TS-2739 > URL: https://issues.apache.org/jira/browse/TS-2739 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Wei Sun >Assignee: Wei Sun > Fix For: 5.0.0 > > > When client is turned off and origin server responds 'Transfer-Encoding: > chunked', ats doesn't send back this header which is required by some clients. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2739) ATS doesn't send back Transfer-Encoding when client keep-alive is turned off
[ https://issues.apache.org/jira/browse/TS-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2739: Description: When client keep-alive is turned off and origin server responds 'Transfer-Encoding: chunked', ats doesn't send back this header which is required by some clients. was: When client is turned off and origin server responds 'Transfer-Encoding: chunked', ats doesn't send back this header which is required by some clients. > ATS doesn't send back Transfer-Encoding when client keep-alive is turned off > > > Key: TS-2739 > URL: https://issues.apache.org/jira/browse/TS-2739 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Wei Sun >Assignee: Wei Sun > Fix For: 5.0.0 > > > When client keep-alive is turned off and origin server responds > 'Transfer-Encoding: chunked', ats doesn't send back this header which is > required by some clients. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2739) ATS doesn't send back Transfer-Encoding when client keep-alive is turned off
[ https://issues.apache.org/jira/browse/TS-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2739: Description: When client keep-alive is turned off and origin server responds 'Transfer-Encoding: chunked', ats doesn't send back this header which is required by some clients. Example: + Incoming O.S. Response + -- State Machine Id: 1 HTTP/1.1 200 OK Accept-Ranges: bytes Cache-Control: max-age=60,public Connection: Keep-Alive Content-Encoding: gzip Content-Type: text/plain; charset=utf-8 Date: Wed, 23 Apr 2014 13:55:28 GMT Etag: "YM:1:3120da04-2938-498f-8dba-d153a0a090ff0004f7b43e3e1bea" Expires: Wed, 23 Apr 2014 13:56:28 GMT Last-Modified: Wed, 23 Apr 2014 11:43:37 GMT Transfer-Encoding: chunked Vary: Accept-Encoding + Proxy's Response 2 + -- State Machine Id: 1 HTTP/1.1 200 OK Accept-Ranges: bytes Cache-Control: max-age=60,public Content-Encoding: gzip Content-Type: text/plain; charset=utf-8 Date: Wed, 23 Apr 2014 13:55:28 GMT Etag: "YM:1:3120da04-2938-498f-8dba-d153a0a090ff0004f7b43e3e1bea" Expires: Wed, 23 Apr 2014 13:56:28 GMT Last-Modified: Wed, 23 Apr 2014 11:43:37 GMT Server: ATS Vary: Accept-Encoding Age: 0 Connection: close was: When client keep-alive is turned off and origin server responds 'Transfer-Encoding: chunked', ats doesn't send back this header which is required by some clients. > ATS doesn't send back Transfer-Encoding when client keep-alive is turned off > > > Key: TS-2739 > URL: https://issues.apache.org/jira/browse/TS-2739 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Wei Sun >Assignee: Wei Sun > Fix For: 5.0.0 > > > When client keep-alive is turned off and origin server responds > 'Transfer-Encoding: chunked', ats doesn't send back this header which is > required by some clients. > Example: > + Incoming O.S. Response + > -- State Machine Id: 1 > HTTP/1.1 200 OK > Accept-Ranges: bytes > Cache-Control: max-age=60,public > Connection: Keep-Alive > Content-Encoding: gzip > Content-Type: text/plain; charset=utf-8 > Date: Wed, 23 Apr 2014 13:55:28 GMT > Etag: "YM:1:3120da04-2938-498f-8dba-d153a0a090ff0004f7b43e3e1bea" > Expires: Wed, 23 Apr 2014 13:56:28 GMT > Last-Modified: Wed, 23 Apr 2014 11:43:37 GMT > Transfer-Encoding: chunked > Vary: Accept-Encoding > + Proxy's Response 2 + > -- State Machine Id: 1 > HTTP/1.1 200 OK > Accept-Ranges: bytes > Cache-Control: max-age=60,public > Content-Encoding: gzip > Content-Type: text/plain; charset=utf-8 > Date: Wed, 23 Apr 2014 13:55:28 GMT > Etag: "YM:1:3120da04-2938-498f-8dba-d153a0a090ff0004f7b43e3e1bea" > Expires: Wed, 23 Apr 2014 13:56:28 GMT > Last-Modified: Wed, 23 Apr 2014 11:43:37 GMT > Server: ATS > Vary: Accept-Encoding > Age: 0 > Connection: close -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2739) ATS doesn't send back Transfer-Encoding when client keep-alive is turned off
[ https://issues.apache.org/jira/browse/TS-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Sun updated TS-2739: Attachment: TS-2739.diff > ATS doesn't send back Transfer-Encoding when client keep-alive is turned off > > > Key: TS-2739 > URL: https://issues.apache.org/jira/browse/TS-2739 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Wei Sun >Assignee: Wei Sun > Fix For: 5.0.0 > > Attachments: TS-2739.diff > > > When client keep-alive is turned off and origin server responds > 'Transfer-Encoding: chunked', ats doesn't send back this header which is > required by some clients. > Example: > + Incoming O.S. Response + > -- State Machine Id: 1 > HTTP/1.1 200 OK > Accept-Ranges: bytes > Cache-Control: max-age=60,public > Connection: Keep-Alive > Content-Encoding: gzip > Content-Type: text/plain; charset=utf-8 > Date: Wed, 23 Apr 2014 13:55:28 GMT > Etag: "YM:1:3120da04-2938-498f-8dba-d153a0a090ff0004f7b43e3e1bea" > Expires: Wed, 23 Apr 2014 13:56:28 GMT > Last-Modified: Wed, 23 Apr 2014 11:43:37 GMT > Transfer-Encoding: chunked > Vary: Accept-Encoding > + Proxy's Response 2 + > -- State Machine Id: 1 > HTTP/1.1 200 OK > Accept-Ranges: bytes > Cache-Control: max-age=60,public > Content-Encoding: gzip > Content-Type: text/plain; charset=utf-8 > Date: Wed, 23 Apr 2014 13:55:28 GMT > Etag: "YM:1:3120da04-2938-498f-8dba-d153a0a090ff0004f7b43e3e1bea" > Expires: Wed, 23 Apr 2014 13:56:28 GMT > Last-Modified: Wed, 23 Apr 2014 11:43:37 GMT > Server: ATS > Vary: Accept-Encoding > Age: 0 > Connection: close -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-302) -fstrict-aliasing optimizer generates bad code
[
https://issues.apache.org/jira/browse/TS-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978347#comment-13978347
]
James Peach commented on TS-302:
I moved this out of "Patch Available", since the attached patches do not
address the issue of the codebase being strict aliasing safe.
> -fstrict-aliasing optimizer generates bad code
> --
>
> Key: TS-302
> URL: https://issues.apache.org/jira/browse/TS-302
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup
>Reporter: Miles Libbey
>Assignee: Phil Sorber
>Priority: Minor
> Fix For: sometime
>
> Attachments: no-no-fstrict-alias.patch, ts-302.patch
>
>
> (moving from yahoo bug 525119)
> Original description
> by Leif Hedstrom 4 years ago at 2005-12-16 08:41
> Not sure if this is a compiler bug or a code issue on our side, but enabling
> the
> -fstrict-aliasing optimization option generates faulty code. This optimization
> technique is enabled implicitly with -Os, -O2 and -O3, so for now I'm
> explicitly
> turning it off with
>-O3 -fno-strict-aliasing
> This solves the problem where the traffic server would return data of 0 or 1
> length out of the cache. This initially looked like the cache corruption
> problem, but is completely different and unrelated. The cache corruption
> problem
> has been fixed and closed.
> I'm opening this bug as a reminder, at some point we should isolate which code
> triggers the strict-aliasing problem, and confirm if it's a compiler bug or a
> problem in our code.
>
>
> Comment 1
> by Michael Bigby 4 years ago at 2005-12-16 09:07:40
> I'm recommending that we get Ed's input on this. He may some insight compiler
> issues...
>
>
> Comment 2
> by Leif Hedstrom 4 years ago at 2005-12-16 10:02:07
> That'd be great!
> We haven't had a chance yet to review the code that might be affecting this,
> it's obviously something with unions and how the compiler handles
> storage/alignment on the members.
>
>
> Comment 3
> by Ed Hall 4 years ago at 2006-03-03 11:46:52
> This is with gcc 2.95.3, correct? There have been a number of complaints
> around
> the 'net about problems with -fstrict-aliasing. I've not really looked very
> deeply into it, though I should mention that certain C code was known at the
> time to malfunction when by-the-standard aliasing rules were enforced
> (starting
> with the Linux kernel).
> In essense, the -fstrict-aliasing optimizations assume that any particular
> part
> of memory accessed via a specific type of pointer won't be accessed as another
> type. There are a set of optimizations that are safe only when it can be
> guaranteed that a given bit of memory hasn't been manipulated via pointer; if
> the compiler assumes that the rather arcane C aliasing rules have been
> followed
> ("aliasing" in this case meaning accessing a given bit of memory with more
> than
> one type of pointer), there are more situations where such optimizations can
> be
> applied. Code which uses type casts where unions might be more appropriate is
> the most likely to break aliasing rules.
> In any case, gcc 3/4 is less aggressive (and perhaps less buggy) in applying
> the
> C aliasing rules, and has added warnings for obvious violations. It's never
> been clear to me if gcc 2.95.3 was actually broken or not, or if there simply
> was a lot of code out there that ran afoul of the standard.
>
>
> Comment 4
> by Leif Hedstrom 4 years ago at 2006-03-03 12:50:22
> Actually, the problem only occured after we converted the code from gcc-2.9x
> to
> gcc-3.4.4. We have since cleared out a *lot* of compiler warnings (thousands
> and
> thousands), so maybe we should try again to compile without the
> -fno-strict-aliasing, and see if gcc will point us to some places where we do
> dangerous things. The code does some very scary things manipulating objects
> directly, by byte-offsets for instance.
> I think it's pretty easy to reproduce the problem, it basically renders the
> cache completely useless, returning objects of size 0 or 1.
>
>
> Comment 5
> by Ed Hall 4 years ago at 2006-03-03 16:44:04
> Ah, that makes sense. I just checked, and the -fstrict-aliasing option wasn't
> part of the -O2 optimizations on gcc 2.95, but got added sometime during gcc 3
> development.
>
>
> Comment 6
> by Ed Hall 4 years ago at 2006-03-03 16:46:43
> (Just to be clear, -fstrict-aliasing was *available* with gcc 2.95.3, it just
> wasn't activated by the -O optimization flags.)
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2740) Add configuration control to turn on SPDY capability
Sudheer Vinukonda created TS-2740: - Summary: Add configuration control to turn on SPDY capability Key: TS-2740 URL: https://issues.apache.org/jira/browse/TS-2740 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Sudheer Vinukonda Currently, SPDY can only be turned on/off via the build with --enable-spdy option. Would like to add a configuration control to turn on/off SPDY capability (useful to troubleshoot production issues) when built with --enable-spdy option. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2740) Configuration settings to SPDY support in ATS
[ https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2740: -- Description: Currently, SPDY can only be turned on/off via the build with --enable-spdy option. Would like to add a configuration control to turn on/off SPDY capability (useful to troubleshoot production issues) when built with --enable-spdy option. Would like to use this Jira to also add support of any other SPDY related settings that might be useful. was:Currently, SPDY can only be turned on/off via the build with --enable-spdy option. Would like to add a configuration control to turn on/off SPDY capability (useful to troubleshoot production issues) when built with --enable-spdy option. Summary: Configuration settings to SPDY support in ATS (was: Add configuration control to turn on SPDY capability) > Configuration settings to SPDY support in ATS > - > > Key: TS-2740 > URL: https://issues.apache.org/jira/browse/TS-2740 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Sudheer Vinukonda > > Currently, SPDY can only be turned on/off via the build with --enable-spdy > option. Would like to add a configuration control to turn on/off SPDY > capability (useful to troubleshoot production issues) when built with > --enable-spdy option. > Would like to use this Jira to also add support of any other SPDY related > settings that might be useful. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2562) Init script has poor support for Debian/Ubuntu
[ https://issues.apache.org/jira/browse/TS-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978419#comment-13978419 ] ASF subversion and git services commented on TS-2562: - Commit 4ecfe2ddf6db0ad74179f54eb0e3da82177ec088 in trafficserver's branch refs/heads/master from [~rocku] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4ecfe2d ] TS-2562: improve init script support for Debian/Ubuntu > Init script has poor support for Debian/Ubuntu > -- > > Key: TS-2562 > URL: https://issues.apache.org/jira/browse/TS-2562 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Affects Versions: 4.2.0 >Reporter: Tomasz Kuzemko >Assignee: Arno Toell >Priority: Minor > Fix For: 5.0.0 > > Attachments: TS-2562.patch > > > Debian/Ubuntu init script should call log_end_msg to return exit code instead > of log_daemon_msg. Also, it's more informative to print $TS_PACKAGE_NAME > instead of $DESC when reporting service name in start/stop/restart. Last > problem is lack of "status" command. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2362) Backwards cache compatibility for 4.X (read 3.2)
[ https://issues.apache.org/jira/browse/TS-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978425#comment-13978425 ] James Peach commented on TS-2362: - This patch needs to be broken up in to digestible pieces. I suggest starting with the addition diagnostic logging; then add the CryptoHash refactoring and finally the compatibility handling. I think it's also worth spending time on regression tests, given the trouble we have had in this area :-/ > Backwards cache compatibility for 4.X (read 3.2) > > > Key: TS-2362 > URL: https://issues.apache.org/jira/browse/TS-2362 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Labels: Review > Fix For: 5.0.0 > > Attachments: ts-2362.diff > > > Enable the 4.X series to be able to read 3.2 caches. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-645) Hard restart in the mgmt APIs is totally busted
[ https://issues.apache.org/jira/browse/TS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978459#comment-13978459 ] ASF subversion and git services commented on TS-645: Commit a2d3a52a67d963eea71871b92572b063e33c7aaf in trafficserver's branch refs/heads/master from [~i.galic] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a2d3a52 ] TS-645: remove StopTrafficServer() and StartTrafficServer() from traffic_shell > Hard restart in the mgmt APIs is totally busted > --- > > Key: TS-645 > URL: https://issues.apache.org/jira/browse/TS-645 > Project: Traffic Server > Issue Type: Bug > Components: Management API >Reporter: Leif Hedstrom >Assignee: Igor Galić > Labels: A, review > Fix For: 5.0.0 > > > In CoreAPIRemote.cc, in HardRestart(), we assume to find some start / stop > scripts that no longer exists: > Layout::relative_to(start_path, sizeof(start_path), Layout::get()->bindir, > "start_traffic_server"); > Layout::relative_to(stop_path, sizeof(stop_path), Layout::get()->bindir, > "stop_traffic_server"); > I don't know if / when this would be used (probably only in the deprecated > Web GUI at this point), but we should fix this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-645) Hard restart in the mgmt APIs is totally busted
[ https://issues.apache.org/jira/browse/TS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978457#comment-13978457 ] ASF subversion and git services commented on TS-645: Commit 51b979e9afa89a64d1adea63508ab4f654f804f5 in trafficserver's branch refs/heads/master from [~i.galic] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=51b979e ] TS-645: remove calls in which hard restart is used It's hard to tell what this is useful for when you have upstart, systemd, SMF and others controling. Aside from being implemented poorly via system(3), it's an API breakage, which is why we're putting it into 5.0.x > Hard restart in the mgmt APIs is totally busted > --- > > Key: TS-645 > URL: https://issues.apache.org/jira/browse/TS-645 > Project: Traffic Server > Issue Type: Bug > Components: Management API >Reporter: Leif Hedstrom >Assignee: Igor Galić > Labels: A, review > Fix For: 5.0.0 > > > In CoreAPIRemote.cc, in HardRestart(), we assume to find some start / stop > scripts that no longer exists: > Layout::relative_to(start_path, sizeof(start_path), Layout::get()->bindir, > "start_traffic_server"); > Layout::relative_to(stop_path, sizeof(stop_path), Layout::get()->bindir, > "stop_traffic_server"); > I don't know if / when this would be used (probably only in the deprecated > Web GUI at this point), but we should fix this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-645) Hard restart in the mgmt APIs is totally busted
[ https://issues.apache.org/jira/browse/TS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978458#comment-13978458 ] ASF subversion and git services commented on TS-645: Commit a3b17cc911e2833b1f5e48dfcaf41a1a2d0cd530 in trafficserver's branch refs/heads/master from [~i.galic] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a3b17cc ] TS-645: remove references to StartTrafficServer() and StopTrafficServer() The reason we remove those functions (ConfigClock, ConfigDate, ConfitTime, etc..) is because they are entirely Linux specific, use hard-coded paths, and assume that our Admins, while clue-less, will know how to use this undocumented traffic_shell program > Hard restart in the mgmt APIs is totally busted > --- > > Key: TS-645 > URL: https://issues.apache.org/jira/browse/TS-645 > Project: Traffic Server > Issue Type: Bug > Components: Management API >Reporter: Leif Hedstrom >Assignee: Igor Galić > Labels: A, review > Fix For: 5.0.0 > > > In CoreAPIRemote.cc, in HardRestart(), we assume to find some start / stop > scripts that no longer exists: > Layout::relative_to(start_path, sizeof(start_path), Layout::get()->bindir, > "start_traffic_server"); > Layout::relative_to(stop_path, sizeof(stop_path), Layout::get()->bindir, > "stop_traffic_server"); > I don't know if / when this would be used (probably only in the deprecated > Web GUI at this point), but we should fix this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2740) Configuration settings to SPDY support in ATS
[ https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978515#comment-13978515 ] James Peach commented on TS-2740: - There's 3 ways to get to SPDY 1. ALPN+NPN 2. explicitly on a given port (TLS is optional) 3. implicitly by byte sniffing We need to be able to control all of these options in configuration. ALPN in particular requires control over the protocol selection, see TS-2565. > Configuration settings to SPDY support in ATS > - > > Key: TS-2740 > URL: https://issues.apache.org/jira/browse/TS-2740 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Sudheer Vinukonda > > Currently, SPDY can only be turned on/off via the build with --enable-spdy > option. Would like to add a configuration control to turn on/off SPDY > capability (useful to troubleshoot production issues) when built with > --enable-spdy option. > Would like to use this Jira to also add support of any other SPDY related > settings that might be useful. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2616) Multiple Transfer-Encoding: chunked headers are not sanitized
[
https://issues.apache.org/jira/browse/TS-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-2616:
---
Assignee: James Peach (was: Leif Hedstrom)
I think that this patch looks reasonable and I'm going to merge it. [~zwoop] if
you disagree, please whack me :)
> Multiple Transfer-Encoding: chunked headers are not sanitized
> -
>
> Key: TS-2616
> URL: https://issues.apache.org/jira/browse/TS-2616
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Dimitry Andric
>Assignee: James Peach
> Labels: review
> Fix For: 5.0.0
>
> Attachments: fix-ts-2616-1.diff
>
>
> I encountered an origin server which sometimes sends multiple copies of the
> same header. Obviously, this origin server is buggy, but I cannot touch it,
> or modify it in any way. An example of such a request:
> {noformat}
> CLIENT> GET /example/request?token=12345678 HTTP/1.1
> CLIENT> Host: 192.168.42.42:8080
> CLIENT> Accept-Encoding: deflate, gzip
> CLIENT> User-Agent: Mozilla/5.0 (Mac OS X; en-us) AppleWebKit/535.7.0 (KHTML,
> like Gecko) Version/4.0.4 Mobile/7B334b Safari/535.7.0
> CLIENT> Accept: application/json
> CLIENT> Referer: http://example.com/
> CLIENT> Client-ip: 127.0.0.1
> CLIENT> X-Forwarded-For: 127.0.0.1
> CLIENT> Via: http/1.1
> trafficserver.localdomain[FF11]
> (ApacheTrafficServer/4.0.2)
> CLIENT>
> SERVER> HTTP/1.1 200 OK
> SERVER> Access-Control-Allow-Origin: *
> SERVER> Access-Control-Allow-Headers : Content-Type
> SERVER> Access-Control-Allow-Methods : GET, PUT, POST, DELETE
> SERVER> Server: Apache-Coyote/1.1
> SERVER> Transfer-Encoding: chunked
> SERVER> Content-Encoding: gzip
> SERVER> Vary: Accept-Encoding
> SERVER> Date: Tue, 04 Feb 2014 13:55:56 GMT
> SERVER> Transfer-Encoding: chunked
> SERVER>
> SERVER> 14
> SERVER>
> SERVER> 0
> {noformat}
> When this request is initially passed through by TrafficServer, the client
> sees at least one "Transfer-Encoding: chunked" header, and assumes a chunked
> transfer. Everything works fine.
> After TrafficServer has cached the request, subsequent requests from the
> client will receive a non-chunked transfer. However, while TrafficServer has
> coalesced multiple headers into one, it removes only *one* instance of the
> "chunked" value:
> {noformat}
> CLIENT> GET http://192.168.42.42:8080/example/request?token=12345678 HTTP/1.1
> CLIENT> Host: 192.168.42.42
> CLIENT> Accept-Encoding: deflate, gzip
> CLIENT> Proxy-Connection: Keep-Alive
> CLIENT> User-Agent: Mozilla/5.0 (Mac OS X; en-us) AppleWebKit/535.7.0 (KHTML,
> like Gecko) Version/4.0.4 Mobile/7B334b Safari/535.7.0
> CLIENT> Accept: application/json
> CLIENT> Referer: http://example.com/
> CLIENT>
> SERVER> HTTP/1.1 200 OK
> SERVER> Access-Control-Allow-Origin: *
> SERVER> Access-Control-Allow-Headers : Content-Type
> SERVER> Access-Control-Allow-Methods : GET, PUT, POST, DELETE
> SERVER> Server: ATS/4.0.2
> SERVER> Content-Encoding: gzip
> SERVER> Vary: Accept-Encoding
> SERVER> Date: Tue, 04 Feb 2014 13:57:36 GMT
> SERVER> Transfer-Encoding: chunked
> SERVER> Age: 1546
> SERVER> Content-Length: 20
> SERVER> Proxy-Connection: keep-alive
> SERVER>
> SERVER>
> {noformat}
> Now the client sees both a "Content-Length: 20" and "Transfer-Encoding:
> chunked" header, which should not happen. When e.g. curl is used as a
> client, it will assume the transfer is chunked, and it attempts to parse the
> initial bytes as a hexadecimal size line. Of course this fails, since there
> is no real chunked transfer, and curl will abort the transfer with an error,
> after reading approximately 256 kiB.
> The problem is due to a piece of code in
> HttpTransact::initialize_state_variables_from_response(), which scans the
> Transfer-Encoding: headers, coalesces them, and removes any "chunked" value
> from them. However, it does not handle multiple "chunked" values, as
> explicitly noticed in a comment on line 5795:
> {noformat}
> 5720 void
> 5721 HttpTransact::initialize_state_variables_from_response(State* s,
> HTTPHdr* incoming_response)
> 5722 {
> ...
> 5785if (incoming_response->presence(MIME_PRESENCE_TRANSFER_ENCODING)) {
> 5786 MIMEField *field =
> incoming_response->field_find(MIME_FIELD_TRANSFER_ENCODING,
> MIME_LEN_TRANSFER_ENCODING);
> ...
> 5792 while (enc_value) {
> 5793const char *wks_value = hdrtoken_string_to_wks(enc_value,
> enc_val_len);
> 5794
> 5795// FIX ME: What is chunked appears more than once? Old
> 5796// code didn't deal with this so I don't either
> 5797if (wks_value == HTTP_VALUE_CHUNKED) {
> ...
> 5813 // Loop over the all the values in existin
[jira] [Commented] (TS-2616) Multiple Transfer-Encoding: chunked headers are not sanitized
[
https://issues.apache.org/jira/browse/TS-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978832#comment-13978832
]
ASF subversion and git services commented on TS-2616:
-
Commit 94ed95b15ee7486eb7286d05ac65117690808ecf in trafficserver's branch
refs/heads/master from [~dim]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=94ed95b ]
TS-2616: Sanitize duplicate Transfer-Encoding: chunked headers
> Multiple Transfer-Encoding: chunked headers are not sanitized
> -
>
> Key: TS-2616
> URL: https://issues.apache.org/jira/browse/TS-2616
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Dimitry Andric
>Assignee: James Peach
> Labels: review
> Fix For: 5.0.0
>
> Attachments: fix-ts-2616-1.diff
>
>
> I encountered an origin server which sometimes sends multiple copies of the
> same header. Obviously, this origin server is buggy, but I cannot touch it,
> or modify it in any way. An example of such a request:
> {noformat}
> CLIENT> GET /example/request?token=12345678 HTTP/1.1
> CLIENT> Host: 192.168.42.42:8080
> CLIENT> Accept-Encoding: deflate, gzip
> CLIENT> User-Agent: Mozilla/5.0 (Mac OS X; en-us) AppleWebKit/535.7.0 (KHTML,
> like Gecko) Version/4.0.4 Mobile/7B334b Safari/535.7.0
> CLIENT> Accept: application/json
> CLIENT> Referer: http://example.com/
> CLIENT> Client-ip: 127.0.0.1
> CLIENT> X-Forwarded-For: 127.0.0.1
> CLIENT> Via: http/1.1
> trafficserver.localdomain[FF11]
> (ApacheTrafficServer/4.0.2)
> CLIENT>
> SERVER> HTTP/1.1 200 OK
> SERVER> Access-Control-Allow-Origin: *
> SERVER> Access-Control-Allow-Headers : Content-Type
> SERVER> Access-Control-Allow-Methods : GET, PUT, POST, DELETE
> SERVER> Server: Apache-Coyote/1.1
> SERVER> Transfer-Encoding: chunked
> SERVER> Content-Encoding: gzip
> SERVER> Vary: Accept-Encoding
> SERVER> Date: Tue, 04 Feb 2014 13:55:56 GMT
> SERVER> Transfer-Encoding: chunked
> SERVER>
> SERVER> 14
> SERVER>
> SERVER> 0
> {noformat}
> When this request is initially passed through by TrafficServer, the client
> sees at least one "Transfer-Encoding: chunked" header, and assumes a chunked
> transfer. Everything works fine.
> After TrafficServer has cached the request, subsequent requests from the
> client will receive a non-chunked transfer. However, while TrafficServer has
> coalesced multiple headers into one, it removes only *one* instance of the
> "chunked" value:
> {noformat}
> CLIENT> GET http://192.168.42.42:8080/example/request?token=12345678 HTTP/1.1
> CLIENT> Host: 192.168.42.42
> CLIENT> Accept-Encoding: deflate, gzip
> CLIENT> Proxy-Connection: Keep-Alive
> CLIENT> User-Agent: Mozilla/5.0 (Mac OS X; en-us) AppleWebKit/535.7.0 (KHTML,
> like Gecko) Version/4.0.4 Mobile/7B334b Safari/535.7.0
> CLIENT> Accept: application/json
> CLIENT> Referer: http://example.com/
> CLIENT>
> SERVER> HTTP/1.1 200 OK
> SERVER> Access-Control-Allow-Origin: *
> SERVER> Access-Control-Allow-Headers : Content-Type
> SERVER> Access-Control-Allow-Methods : GET, PUT, POST, DELETE
> SERVER> Server: ATS/4.0.2
> SERVER> Content-Encoding: gzip
> SERVER> Vary: Accept-Encoding
> SERVER> Date: Tue, 04 Feb 2014 13:57:36 GMT
> SERVER> Transfer-Encoding: chunked
> SERVER> Age: 1546
> SERVER> Content-Length: 20
> SERVER> Proxy-Connection: keep-alive
> SERVER>
> SERVER>
> {noformat}
> Now the client sees both a "Content-Length: 20" and "Transfer-Encoding:
> chunked" header, which should not happen. When e.g. curl is used as a
> client, it will assume the transfer is chunked, and it attempts to parse the
> initial bytes as a hexadecimal size line. Of course this fails, since there
> is no real chunked transfer, and curl will abort the transfer with an error,
> after reading approximately 256 kiB.
> The problem is due to a piece of code in
> HttpTransact::initialize_state_variables_from_response(), which scans the
> Transfer-Encoding: headers, coalesces them, and removes any "chunked" value
> from them. However, it does not handle multiple "chunked" values, as
> explicitly noticed in a comment on line 5795:
> {noformat}
> 5720 void
> 5721 HttpTransact::initialize_state_variables_from_response(State* s,
> HTTPHdr* incoming_response)
> 5722 {
> ...
> 5785if (incoming_response->presence(MIME_PRESENCE_TRANSFER_ENCODING)) {
> 5786 MIMEField *field =
> incoming_response->field_find(MIME_FIELD_TRANSFER_ENCODING,
> MIME_LEN_TRANSFER_ENCODING);
> ...
> 5792 while (enc_value) {
> 5793const char *wks_value = hdrtoken_string_to_wks(enc_value,
> enc_val_len);
> 5794
> 5795// FIX ME: What is chunked appears more than once? Old
> 5796/
[jira] [Updated] (TS-2741) server intercept examples and documentation
[ https://issues.apache.org/jira/browse/TS-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2741: Priority: Minor (was: Major) Fix Version/s: 5.0.0 Assignee: James Peach > server intercept examples and documentation > --- > > Key: TS-2741 > URL: https://issues.apache.org/jira/browse/TS-2741 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Fix For: 5.0.0 > > > The server intercept API is not well documented. Additionally, while there > are uses of it in the code, there's not good, complete example plugin. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2741) server intercept examples and documentation
James Peach created TS-2741: --- Summary: server intercept examples and documentation Key: TS-2741 URL: https://issues.apache.org/jira/browse/TS-2741 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: James Peach The server intercept API is not well documented. Additionally, while there are uses of it in the code, there's not good, complete example plugin. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2740) Enhancements and Fixes to SPDY support in ATS
[ https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2740: -- Description: Would like to use this Jira to make fixes/enhancements identified during our tests to adapt SPDY in our production environment 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy option. Would like to add a configuration control to turn on/off SPDY capability (useful to troubleshoot production issues) when built with --enable-spdy option. 2. Noticed ATS crashing with the below stack trace during production. Looks like TsFetchCreate() asserts for non-ipv4 address. [TrafficServer] using root directory '/home/y' FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server - STACK TRACE: /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b8d706445c8] /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b8d70642a8f] /home/y/bin/traffic_server(TSFetchCreate+0x57)[0x4b0fb7] /home/y/bin/traffic_server[0x5d24df] /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d32fe] /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718b30] /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719837] /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719a69] /home/y/bin/traffic_server[0x5d09c8] /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed907] /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddb07] /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e4f72] /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f0f] /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x7138b3] FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server[0x7122ba] /lib64/libpthread.so.0(+0x3297207851)[0x2b8d70cdb851] /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] was: Currently, SPDY can only be turned on/off via the build with --enable-spdy option. Would like to add a configuration control to turn on/off SPDY capability (useful to troubleshoot production issues) when built with --enable-spdy option. Would like to use this Jira to also add support of any other SPDY related settings that might be useful. Summary: Enhancements and Fixes to SPDY support in ATS (was: Configuration settings to SPDY support in ATS) Thanks for the inputs, James - I've modified the ticket to track all the issues identified during our SPDY adaption. > Enhancements and Fixes to SPDY support in ATS > - > > Key: TS-2740 > URL: https://issues.apache.org/jira/browse/TS-2740 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Sudheer Vinukonda > > Would like to use this Jira to make fixes/enhancements identified during our > tests to adapt SPDY in our production environment > 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy > option. Would like to add a configuration control to turn on/off SPDY > capability (useful to troubleshoot production issues) when built with > --enable-spdy option. > 2. Noticed ATS crashing with the below stack trace during production. Looks > like TsFetchCreate() asserts for non-ipv4 address. > [TrafficServer] using root directory '/home/y' > FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` > /home/y/bin/traffic_server - STACK TRACE: > /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b8d706445c8] > /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b8d70642a8f] > /home/y/bin/traffic_server(TSFetchCreate+0x57)[0x4b0fb7] > /home/y/bin/traffic_server[0x5d24df] > /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d32fe] > /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718b30] > /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719837] > /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719a69] > /home/y/bin/traffic_server[0x5d09c8] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed907] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddb07] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e4f72] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f0f] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x7138b3] > FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` > /home/y/bin/traffic_server[0x7122ba] > /lib64/libpthread.so.0(+0x3297207851)[0x2b8d70cdb851] > /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2740) Configuration settings to SPDY support in ATS
[ https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2740: Summary: Configuration settings to SPDY support in ATS (was: Enhancements and Fixes to SPDY support in ATS) > Configuration settings to SPDY support in ATS > - > > Key: TS-2740 > URL: https://issues.apache.org/jira/browse/TS-2740 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Sudheer Vinukonda > > Would like to use this Jira to make fixes/enhancements identified during our > tests to adapt SPDY in our production environment > 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy > option. Would like to add a configuration control to turn on/off SPDY > capability (useful to troubleshoot production issues) when built with > --enable-spdy option. > 2. Noticed ATS crashing with the below stack trace during production. Looks > like TsFetchCreate() asserts for non-ipv4 address. > [TrafficServer] using root directory '/home/y' > FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` > /home/y/bin/traffic_server - STACK TRACE: > /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b8d706445c8] > /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b8d70642a8f] > /home/y/bin/traffic_server(TSFetchCreate+0x57)[0x4b0fb7] > /home/y/bin/traffic_server[0x5d24df] > /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d32fe] > /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718b30] > /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719837] > /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719a69] > /home/y/bin/traffic_server[0x5d09c8] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed907] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddb07] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e4f72] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f0f] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x7138b3] > FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` > /home/y/bin/traffic_server[0x7122ba] > /lib64/libpthread.so.0(+0x3297207851)[0x2b8d70cdb851] > /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2740) Configuration settings to SPDY support in ATS
[ https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978878#comment-13978878 ] James Peach commented on TS-2740: - Let's not do that. One ticket per issue, please. > Configuration settings to SPDY support in ATS > - > > Key: TS-2740 > URL: https://issues.apache.org/jira/browse/TS-2740 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Sudheer Vinukonda > > Would like to use this Jira to make fixes/enhancements identified during our > tests to adapt SPDY in our production environment > 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy > option. Would like to add a configuration control to turn on/off SPDY > capability (useful to troubleshoot production issues) when built with > --enable-spdy option. > 2. Noticed ATS crashing with the below stack trace during production. Looks > like TsFetchCreate() asserts for non-ipv4 address. > [TrafficServer] using root directory '/home/y' > FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` > /home/y/bin/traffic_server - STACK TRACE: > /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b8d706445c8] > /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b8d70642a8f] > /home/y/bin/traffic_server(TSFetchCreate+0x57)[0x4b0fb7] > /home/y/bin/traffic_server[0x5d24df] > /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d32fe] > /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718b30] > /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719837] > /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719a69] > /home/y/bin/traffic_server[0x5d09c8] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed907] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddb07] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e4f72] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f0f] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x7138b3] > FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` > /home/y/bin/traffic_server[0x7122ba] > /lib64/libpthread.so.0(+0x3297207851)[0x2b8d70cdb851] > /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2741) server intercept examples and documentation
[ https://issues.apache.org/jira/browse/TS-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978883#comment-13978883 ] ASF subversion and git services commented on TS-2741: - Commit eb183eef9e25c28d2244bc7195da61fd47380726 in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=eb183ee ] TS-2741: add a new server intercept example plugin Add a new example plugin to demonstrate the use of TSHttpTxnServerIntercept to proxy origin requests to a secondary server. Document TSHttpTxnServerIntercept, and update surrounding documentation that references it. Add a new test, test-server-intercept, that combines the example plugin and jtest to do an end-to-end test of the intercept API. > server intercept examples and documentation > --- > > Key: TS-2741 > URL: https://issues.apache.org/jira/browse/TS-2741 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Fix For: 5.0.0 > > > The server intercept API is not well documented. Additionally, while there > are uses of it in the code, there's not good, complete example plugin. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2741) server intercept examples and documentation
[ https://issues.apache.org/jira/browse/TS-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-2741. - Resolution: Fixed > server intercept examples and documentation > --- > > Key: TS-2741 > URL: https://issues.apache.org/jira/browse/TS-2741 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: James Peach >Assignee: James Peach >Priority: Minor > Fix For: 5.0.0 > > > The server intercept API is not well documented. Additionally, while there > are uses of it in the code, there's not good, complete example plugin. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2740) Configuration settings to SPDY support in ATS
[ https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978887#comment-13978887 ] Sudheer Vinukonda commented on TS-2740: --- OK, not a problem :) > Configuration settings to SPDY support in ATS > - > > Key: TS-2740 > URL: https://issues.apache.org/jira/browse/TS-2740 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Sudheer Vinukonda > > Would like to use this Jira to make fixes/enhancements identified during our > tests to adapt SPDY in our production environment > 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy > option. Would like to add a configuration control to turn on/off SPDY > capability (useful to troubleshoot production issues) when built with > --enable-spdy option. > 2. Noticed ATS crashing with the below stack trace during production. Looks > like TsFetchCreate() asserts for non-ipv4 address. > [TrafficServer] using root directory '/home/y' > FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` > /home/y/bin/traffic_server - STACK TRACE: > /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b8d706445c8] > /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b8d70642a8f] > /home/y/bin/traffic_server(TSFetchCreate+0x57)[0x4b0fb7] > /home/y/bin/traffic_server[0x5d24df] > /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d32fe] > /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718b30] > /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719837] > /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719a69] > /home/y/bin/traffic_server[0x5d09c8] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed907] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddb07] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e4f72] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f0f] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x7138b3] > FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` > /home/y/bin/traffic_server[0x7122ba] > /lib64/libpthread.so.0(+0x3297207851)[0x2b8d70cdb851] > /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2740) Configuration settings to SPDY support in ATS
[ https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2740: -- Description: Would like to use this Jira to add the configuration settings that might be useful to adapt SPDY on ATS 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy option. Would like to add a configuration control to turn on/off SPDY capability (useful to troubleshoot production issues) when built with --enable-spdy option. was: Would like to use this Jira to make fixes/enhancements identified during our tests to adapt SPDY in our production environment 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy option. Would like to add a configuration control to turn on/off SPDY capability (useful to troubleshoot production issues) when built with --enable-spdy option. 2. Noticed ATS crashing with the below stack trace during production. Looks like TsFetchCreate() asserts for non-ipv4 address. [TrafficServer] using root directory '/home/y' FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server - STACK TRACE: /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b8d706445c8] /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b8d70642a8f] /home/y/bin/traffic_server(TSFetchCreate+0x57)[0x4b0fb7] /home/y/bin/traffic_server[0x5d24df] /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d32fe] /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718b30] /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719837] /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719a69] /home/y/bin/traffic_server[0x5d09c8] /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed907] /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddb07] /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e4f72] /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f0f] /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x7138b3] FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server[0x7122ba] /lib64/libpthread.so.0(+0x3297207851)[0x2b8d70cdb851] /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] > Configuration settings to SPDY support in ATS > - > > Key: TS-2740 > URL: https://issues.apache.org/jira/browse/TS-2740 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Sudheer Vinukonda > > Would like to use this Jira to add the configuration settings that might be > useful to adapt SPDY on ATS > 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy > option. Would like to add a configuration control to turn on/off SPDY > capability (useful to troubleshoot production issues) when built with > --enable-spdy option. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2742) Crash with SPDY on production environment
Sudheer Vinukonda created TS-2742: - Summary: Crash with SPDY on production environment Key: TS-2742 URL: https://issues.apache.org/jira/browse/TS-2742 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Noticed ATS crashing with the below stack trace during production. Looks like TsFetchCreate() asserts for non-ipv4 address. [TrafficServer] using root directory '/home/y' FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server - STACK TRACE: /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b8d706445c8] /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b8d70642a8f] /home/y/bin/traffic_server(TSFetchCreate+0x57)[0x4b0fb7] /home/y/bin/traffic_server[0x5d24df] /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d32fe] /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718b30] /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719837] /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719a69] /home/y/bin/traffic_server[0x5d09c8] /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed907] /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddb07] /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e4f72] /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f0f] /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x7138b3] FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` /home/y/bin/traffic_server[0x7122ba] /lib64/libpthread.so.0(+0x3297207851)[0x2b8d70cdb851] /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2433) Size threshold for SSL request
[ https://issues.apache.org/jira/browse/TS-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-2433. - Resolution: Won't Fix I don't think that this patch is desirable or really addresses the issue. If you have a new patch that addresses the large post problem in a general way, please re-open this, or file a new ticket. Thanks. > Size threshold for SSL request > -- > > Key: TS-2433 > URL: https://issues.apache.org/jira/browse/TS-2433 > Project: Traffic Server > Issue Type: Task > Components: SSL >Reporter: Wei Sun >Assignee: Wei Sun > Labels: Review > Fix For: 5.0.0 > > Attachments: TS-2433.diff > > > A size threshold is expected for client request over SSL, if the max > requested data(SSL_read) exceeds the threshold, close the connection. > Default: no size limitation. We have this use case when using stunnel, expect > to have the same functionality in ATS. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2740) SPDY - Configuration settings to SPDY support in ATS
[ https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2740: -- Summary: SPDY - Configuration settings to SPDY support in ATS (was: Configuration settings to SPDY support in ATS) Adding a SPDY_ATS tag to be able to group easily all related tickets > SPDY - Configuration settings to SPDY support in ATS > > > Key: TS-2740 > URL: https://issues.apache.org/jira/browse/TS-2740 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Sudheer Vinukonda > > Would like to use this Jira to add the configuration settings that might be > useful to adapt SPDY on ATS > 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy > option. Would like to add a configuration control to turn on/off SPDY > capability (useful to troubleshoot production issues) when built with > --enable-spdy option. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2584) failed assert transforming and caching negative response
[
https://issues.apache.org/jira/browse/TS-2584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2584:
Labels: (was: Review)
> failed assert transforming and caching negative response
>
>
> Key: TS-2584
> URL: https://issues.apache.org/jira/browse/TS-2584
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Jack Bates
> Fix For: 5.0.0
>
>
> If negative caching is enabled and you transform a negative response (for
> example a null transform) there is a failed assert in
> HttpTransact::set_headers_for_cache_write()
> {noformat}
> FATAL: HttpTransact.cc:4811: failed assert
> `cache_info->response_get()->valid()`
> proxy/.libs/lt-traffic_server - STACK TRACE:
> lib/ts/.libs/libtsutil.so.5(ink_fatal_die+0x0)[0xb77a6445]
> lib/ts/.libs/libtsutil.so.5(+0x22269)[0xb77a5269]
> proxy/.libs/lt-traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0x1da)[0x81c0ae6]
> proxy/.libs/lt-traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x272)[0x81c0576]
> proxy/.libs/lt-traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x78)[0x81a4b3e]
> proxy/.libs/lt-traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0x196)[0x81926b0]
> proxy/.libs/lt-traffic_server(_ZN6HttpSM12main_handlerEiPv+0x2df)[0x81969b5]
> proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x811b427]
> proxy/.libs/lt-traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x27f)[0x815d81b]
> proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x811b427]
> proxy/.libs/lt-traffic_server(_ZN7EThread13process_eventEP5Eventi+0x104)[0x8300692]
> proxy/.libs/lt-traffic_server(_ZN7EThread7executeEv+0xd6)[0x8300916]
> proxy/.libs/lt-traffic_server[0x82ff569]
> /lib/i686/cmov/libpthread.so.0(+0x5955)[0xb7467955]
> /lib/i686/cmov/libc.so.6(clone+0x5e)[0xb717f1de]
> Aborted (core dumped)
> {noformat}
> HttpTransact::handle_transform_ready() passes s->cache_info.transform_store
> to HttpTransact::set_headers_for_cache_write()
> The ->valid() test at the top of HttpTransact::set_headers_for_cache_write()
> fails so ->create() gets called.
> {code}
> if (!cache_info->valid()) {
> cache_info->create();
> }
> {code}
> (s->cache_info.transform_store->m_alt is NULL. I didn't look into why this
> is, is it expected?)
> Because s->negative_caching is true, cache_info->response_set(response)
> doesn't get called, instead the assert fails.
> {code}
> if (!s->negative_caching)
> cache_info->response_set(response);
> else {
> ink_assert(cache_info->response_get()->valid());
> }
> {code}
> Assuming the cache_info->valid() test can fail and s->negative_caching can be
> true at the same time, one possible solution is to fix the logic so
> cache_info->response_set(response) gets called?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2740) SPDY_ATS - Configuration settings to SPDY support in ATS
[ https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2740: -- Summary: SPDY_ATS - Configuration settings to SPDY support in ATS (was: SPDY - Configuration settings to SPDY support in ATS) > SPDY_ATS - Configuration settings to SPDY support in ATS > > > Key: TS-2740 > URL: https://issues.apache.org/jira/browse/TS-2740 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Sudheer Vinukonda > > Would like to use this Jira to add the configuration settings that might be > useful to adapt SPDY on ATS > 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy > option. Would like to add a configuration control to turn on/off SPDY > capability (useful to troubleshoot production issues) when built with > --enable-spdy option. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2742) SPDY_ATS - Crash with SPDY on production environment
[ https://issues.apache.org/jira/browse/TS-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2742: -- Summary: SPDY_ATS - Crash with SPDY on production environment (was: Crash with SPDY on production environment) > SPDY_ATS - Crash with SPDY on production environment > > > Key: TS-2742 > URL: https://issues.apache.org/jira/browse/TS-2742 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Sudheer Vinukonda > > Noticed ATS crashing with the below stack trace during production. Looks like > TsFetchCreate() asserts for non-ipv4 address. > [TrafficServer] using root directory '/home/y' > FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` > /home/y/bin/traffic_server - STACK TRACE: > /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b8d706445c8] > /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b8d70642a8f] > /home/y/bin/traffic_server(TSFetchCreate+0x57)[0x4b0fb7] > /home/y/bin/traffic_server[0x5d24df] > /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d32fe] > /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718b30] > /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719837] > /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719a69] > /home/y/bin/traffic_server[0x5d09c8] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed907] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddb07] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e4f72] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f0f] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x7138b3] > FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` > /home/y/bin/traffic_server[0x7122ba] > /lib64/libpthread.so.0(+0x3297207851)[0x2b8d70cdb851] > /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2742) SPDY_ATS - Crash with SPDY on production environment in TsFetchCreate()
[ https://issues.apache.org/jira/browse/TS-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-2742: -- Summary: SPDY_ATS - Crash with SPDY on production environment in TsFetchCreate() (was: SPDY_ATS - Crash with SPDY on production environment) > SPDY_ATS - Crash with SPDY on production environment in TsFetchCreate() > --- > > Key: TS-2742 > URL: https://issues.apache.org/jira/browse/TS-2742 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Sudheer Vinukonda > > Noticed ATS crashing with the below stack trace during production. Looks like > TsFetchCreate() asserts for non-ipv4 address. > [TrafficServer] using root directory '/home/y' > FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` > /home/y/bin/traffic_server - STACK TRACE: > /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b8d706445c8] > /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b8d70642a8f] > /home/y/bin/traffic_server(TSFetchCreate+0x57)[0x4b0fb7] > /home/y/bin/traffic_server[0x5d24df] > /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d32fe] > /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718b30] > /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719837] > /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719a69] > /home/y/bin/traffic_server[0x5d09c8] > /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed907] > /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddb07] > /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e4f72] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f0f] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x7138b3] > FATAL: InkAPI.cc:7295: failed assert `ats_is_ip4(client_addr)` > /home/y/bin/traffic_server[0x7122ba] > /lib64/libpthread.so.0(+0x3297207851)[0x2b8d70cdb851] > /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2743) SPDY_ATS - Crash with SPDY on production environment in SpdyNV::SpdyNV
Sudheer Vinukonda created TS-2743: - Summary: SPDY_ATS - Crash with SPDY on production environment in SpdyNV::SpdyNV Key: TS-2743 URL: https://issues.apache.org/jira/browse/TS-2743 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda After patching a fix (by removing the apparent incorrect assert failure on non-ipv4 address in TsFetchCreate - jira ts-2742), noticed a new crash, this time in SpdyNV::SpdyNV with the below stack trace. Will update more upon investigation. FATAL: SpdyCommon.cc:133: failed assert `value && value_len` FATAL: SpdyCommon.cc:133: failed assert `value && value_len` /home/y/bin/traffic_server - STACK TRACE: /home/y/bin/traffic_server - STACK TRACE: /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b7371f6a5c8] /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b7371f6a5c8] /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b7371f68a8f] /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b7371f68a8f] /home/y/bin/traffic_server[0x4af739] /home/y/bin/traffic_server[0x5cf7ea] /home/y/bin/traffic_server[0x5d0a6a] /home/y/bin/traffic_server(_ZN7FetchSM15InvokePluginExtEi+0x33a)[0x4c7a5a] /home/y/bin/traffic_server[0x4af739] /home/y/bin/traffic_server(_ZN7FetchSM18process_fetch_readEi+0x187)[0x4c7f37] /home/y/bin/traffic_server[0x5cf7ea] /home/y/bin/traffic_server[0x5d0a6a] /home/y/bin/traffic_server(_ZN7FetchSM15InvokePluginExtEi+0x33a)[0x4c7a5a] /home/y/bin/traffic_server(_ZN7FetchSM18process_fetch_readEi+0x187)[0x4c7f37] /home/y/bin/traffic_server(_ZN7FetchSM13fetch_handlerEiPv+0x8b)[0x4c80eb] /home/y/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x375)[0x4dd0d5] /home/y/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x57a)[0x4dda2a] /home/y/bin/traffic_server(_ZN7FetchSM13fetch_handlerEiPv+0x8b)[0x4c80eb] /home/y/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x372)[0x4de272] /home/y/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x375)[0x4dd0d5] /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f7f] /home/y/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x57a)[0x4dda2a] /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x713aab] /home/y/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x372)[0x4de272] /home/y/bin/traffic_server[0x71232a] /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f7f] /lib64/libpthread.so.0(+0x3297207851)[0x2b7372601851] /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x713aab] /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] /home/y/bin/traffic_server[0x71232a] /lib64/libpthread.so.0(+0x3297207851)[0x2b7372601851] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2743) SPDY_ATS - Crash with SPDY on production environment in SpdyNV::SpdyNV
[
https://issues.apache.org/jira/browse/TS-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2743:
--
It looks like the code may have an issue. There may be non string type http
headers (e.g Expires), which will fail the assert.
SpdyNV::SpdyNV(TSFetchSM fetch_sm)
{
//
//...
value = TSMimeHdrFieldValueStringGet(bufp, loc, field_loc, -1, &value_len);
TSReleaseAssert(value && value_len);
//
To confirm, did a simple test by replacing the assert with an error log and
noticed the below errors coming out a lot and the core dump looks to be fixed
(although, a new core dump occured - will open a separate jira for that). Will
be trying a patch to try TSMimeHdrFieldValueIntGet() if the
TSMimeHdrFieldValueStringGet() fails.
20140423.23h05m42s Spdy Error in processing hdr Expires of field length 7
> SPDY_ATS - Crash with SPDY on production environment in SpdyNV::SpdyNV
> --
>
> Key: TS-2743
> URL: https://issues.apache.org/jira/browse/TS-2743
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Sudheer Vinukonda
>
> After patching a fix (by removing the apparent incorrect assert failure on
> non-ipv4 address in TsFetchCreate - jira ts-2742), noticed a new crash, this
> time in SpdyNV::SpdyNV with the below stack trace. Will update more upon
> investigation.
> FATAL: SpdyCommon.cc:133: failed assert `value && value_len`
> FATAL: SpdyCommon.cc:133: failed assert `value && value_len`
> /home/y/bin/traffic_server - STACK TRACE:
> /home/y/bin/traffic_server - STACK TRACE:
> /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b7371f6a5c8]
> /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b7371f6a5c8]
> /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b7371f68a8f]
> /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b7371f68a8f]
> /home/y/bin/traffic_server[0x4af739]
> /home/y/bin/traffic_server[0x5cf7ea]
> /home/y/bin/traffic_server[0x5d0a6a]
> /home/y/bin/traffic_server(_ZN7FetchSM15InvokePluginExtEi+0x33a)[0x4c7a5a]
> /home/y/bin/traffic_server[0x4af739]
> /home/y/bin/traffic_server(_ZN7FetchSM18process_fetch_readEi+0x187)[0x4c7f37]
> /home/y/bin/traffic_server[0x5cf7ea]
> /home/y/bin/traffic_server[0x5d0a6a]
> /home/y/bin/traffic_server(_ZN7FetchSM15InvokePluginExtEi+0x33a)[0x4c7a5a]
> /home/y/bin/traffic_server(_ZN7FetchSM18process_fetch_readEi+0x187)[0x4c7f37]
> /home/y/bin/traffic_server(_ZN7FetchSM13fetch_handlerEiPv+0x8b)[0x4c80eb]
> /home/y/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x375)[0x4dd0d5]
> /home/y/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x57a)[0x4dda2a]
> /home/y/bin/traffic_server(_ZN7FetchSM13fetch_handlerEiPv+0x8b)[0x4c80eb]
> /home/y/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x372)[0x4de272]
> /home/y/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x375)[0x4dd0d5]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f7f]
> /home/y/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x57a)[0x4dda2a]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x713aab]
> /home/y/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x372)[0x4de272]
> /home/y/bin/traffic_server[0x71232a]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f7f]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b7372601851]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x713aab]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
> /home/y/bin/traffic_server[0x71232a]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b7372601851]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2743) SPDY_ATS - Crash with SPDY on production environment in SpdyNV::SpdyNV
[
https://issues.apache.org/jira/browse/TS-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979064#comment-13979064
]
Sudheer Vinukonda edited comment on TS-2743 at 4/23/14 11:21 PM:
-
It looks like the code may have an issue. There may be non string type http
headers (e.g Expires), which will fail the assert.
SpdyNV::SpdyNV(TSFetchSM fetch_sm)
{
//
//...
value = TSMimeHdrFieldValueStringGet(bufp, loc, field_loc, -1, &value_len);
TSReleaseAssert(value && value_len);
//
To confirm, did a simple test by replacing the assert with an error log and
noticed the below errors coming out a lot and the core dump looks to be fixed
(although, a new core dump occured - will open a separate jira for that). Will
be trying a patch to try TSMimeHdrFieldValueDateGet() if the
TSMimeHdrFieldValueStringGet() fails.
20140423.23h05m42s Spdy Error in processing hdr Expires of field length 7
was (Author: sudheerv):
It looks like the code may have an issue. There may be non string type http
headers (e.g Expires), which will fail the assert.
SpdyNV::SpdyNV(TSFetchSM fetch_sm)
{
//
//...
value = TSMimeHdrFieldValueStringGet(bufp, loc, field_loc, -1, &value_len);
TSReleaseAssert(value && value_len);
//
To confirm, did a simple test by replacing the assert with an error log and
noticed the below errors coming out a lot and the core dump looks to be fixed
(although, a new core dump occured - will open a separate jira for that). Will
be trying a patch to try TSMimeHdrFieldValueIntGet() if the
TSMimeHdrFieldValueStringGet() fails.
20140423.23h05m42s Spdy Error in processing hdr Expires of field length 7
> SPDY_ATS - Crash with SPDY on production environment in SpdyNV::SpdyNV
> --
>
> Key: TS-2743
> URL: https://issues.apache.org/jira/browse/TS-2743
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Sudheer Vinukonda
>
> After patching a fix (by removing the apparent incorrect assert failure on
> non-ipv4 address in TsFetchCreate - jira ts-2742), noticed a new crash, this
> time in SpdyNV::SpdyNV with the below stack trace. Will update more upon
> investigation.
> FATAL: SpdyCommon.cc:133: failed assert `value && value_len`
> FATAL: SpdyCommon.cc:133: failed assert `value && value_len`
> /home/y/bin/traffic_server - STACK TRACE:
> /home/y/bin/traffic_server - STACK TRACE:
> /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b7371f6a5c8]
> /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b7371f6a5c8]
> /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b7371f68a8f]
> /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b7371f68a8f]
> /home/y/bin/traffic_server[0x4af739]
> /home/y/bin/traffic_server[0x5cf7ea]
> /home/y/bin/traffic_server[0x5d0a6a]
> /home/y/bin/traffic_server(_ZN7FetchSM15InvokePluginExtEi+0x33a)[0x4c7a5a]
> /home/y/bin/traffic_server[0x4af739]
> /home/y/bin/traffic_server(_ZN7FetchSM18process_fetch_readEi+0x187)[0x4c7f37]
> /home/y/bin/traffic_server[0x5cf7ea]
> /home/y/bin/traffic_server[0x5d0a6a]
> /home/y/bin/traffic_server(_ZN7FetchSM15InvokePluginExtEi+0x33a)[0x4c7a5a]
> /home/y/bin/traffic_server(_ZN7FetchSM18process_fetch_readEi+0x187)[0x4c7f37]
> /home/y/bin/traffic_server(_ZN7FetchSM13fetch_handlerEiPv+0x8b)[0x4c80eb]
> /home/y/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x375)[0x4dd0d5]
> /home/y/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x57a)[0x4dda2a]
> /home/y/bin/traffic_server(_ZN7FetchSM13fetch_handlerEiPv+0x8b)[0x4c80eb]
> /home/y/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x372)[0x4de272]
> /home/y/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x375)[0x4dd0d5]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f7f]
> /home/y/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x57a)[0x4dda2a]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x713aab]
> /home/y/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x372)[0x4de272]
> /home/y/bin/traffic_server[0x71232a]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f7f]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b7372601851]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x713aab]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
> /home/y/bin/traffic_server[0x71232a]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b7372601851]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2616) Multiple Transfer-Encoding: chunked headers are not sanitized
[
https://issues.apache.org/jira/browse/TS-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2616:
Labels: (was: review)
> Multiple Transfer-Encoding: chunked headers are not sanitized
> -
>
> Key: TS-2616
> URL: https://issues.apache.org/jira/browse/TS-2616
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Dimitry Andric
>Assignee: James Peach
> Fix For: 5.0.0
>
> Attachments: fix-ts-2616-1.diff
>
>
> I encountered an origin server which sometimes sends multiple copies of the
> same header. Obviously, this origin server is buggy, but I cannot touch it,
> or modify it in any way. An example of such a request:
> {noformat}
> CLIENT> GET /example/request?token=12345678 HTTP/1.1
> CLIENT> Host: 192.168.42.42:8080
> CLIENT> Accept-Encoding: deflate, gzip
> CLIENT> User-Agent: Mozilla/5.0 (Mac OS X; en-us) AppleWebKit/535.7.0 (KHTML,
> like Gecko) Version/4.0.4 Mobile/7B334b Safari/535.7.0
> CLIENT> Accept: application/json
> CLIENT> Referer: http://example.com/
> CLIENT> Client-ip: 127.0.0.1
> CLIENT> X-Forwarded-For: 127.0.0.1
> CLIENT> Via: http/1.1
> trafficserver.localdomain[FF11]
> (ApacheTrafficServer/4.0.2)
> CLIENT>
> SERVER> HTTP/1.1 200 OK
> SERVER> Access-Control-Allow-Origin: *
> SERVER> Access-Control-Allow-Headers : Content-Type
> SERVER> Access-Control-Allow-Methods : GET, PUT, POST, DELETE
> SERVER> Server: Apache-Coyote/1.1
> SERVER> Transfer-Encoding: chunked
> SERVER> Content-Encoding: gzip
> SERVER> Vary: Accept-Encoding
> SERVER> Date: Tue, 04 Feb 2014 13:55:56 GMT
> SERVER> Transfer-Encoding: chunked
> SERVER>
> SERVER> 14
> SERVER>
> SERVER> 0
> {noformat}
> When this request is initially passed through by TrafficServer, the client
> sees at least one "Transfer-Encoding: chunked" header, and assumes a chunked
> transfer. Everything works fine.
> After TrafficServer has cached the request, subsequent requests from the
> client will receive a non-chunked transfer. However, while TrafficServer has
> coalesced multiple headers into one, it removes only *one* instance of the
> "chunked" value:
> {noformat}
> CLIENT> GET http://192.168.42.42:8080/example/request?token=12345678 HTTP/1.1
> CLIENT> Host: 192.168.42.42
> CLIENT> Accept-Encoding: deflate, gzip
> CLIENT> Proxy-Connection: Keep-Alive
> CLIENT> User-Agent: Mozilla/5.0 (Mac OS X; en-us) AppleWebKit/535.7.0 (KHTML,
> like Gecko) Version/4.0.4 Mobile/7B334b Safari/535.7.0
> CLIENT> Accept: application/json
> CLIENT> Referer: http://example.com/
> CLIENT>
> SERVER> HTTP/1.1 200 OK
> SERVER> Access-Control-Allow-Origin: *
> SERVER> Access-Control-Allow-Headers : Content-Type
> SERVER> Access-Control-Allow-Methods : GET, PUT, POST, DELETE
> SERVER> Server: ATS/4.0.2
> SERVER> Content-Encoding: gzip
> SERVER> Vary: Accept-Encoding
> SERVER> Date: Tue, 04 Feb 2014 13:57:36 GMT
> SERVER> Transfer-Encoding: chunked
> SERVER> Age: 1546
> SERVER> Content-Length: 20
> SERVER> Proxy-Connection: keep-alive
> SERVER>
> SERVER>
> {noformat}
> Now the client sees both a "Content-Length: 20" and "Transfer-Encoding:
> chunked" header, which should not happen. When e.g. curl is used as a
> client, it will assume the transfer is chunked, and it attempts to parse the
> initial bytes as a hexadecimal size line. Of course this fails, since there
> is no real chunked transfer, and curl will abort the transfer with an error,
> after reading approximately 256 kiB.
> The problem is due to a piece of code in
> HttpTransact::initialize_state_variables_from_response(), which scans the
> Transfer-Encoding: headers, coalesces them, and removes any "chunked" value
> from them. However, it does not handle multiple "chunked" values, as
> explicitly noticed in a comment on line 5795:
> {noformat}
> 5720 void
> 5721 HttpTransact::initialize_state_variables_from_response(State* s,
> HTTPHdr* incoming_response)
> 5722 {
> ...
> 5785if (incoming_response->presence(MIME_PRESENCE_TRANSFER_ENCODING)) {
> 5786 MIMEField *field =
> incoming_response->field_find(MIME_FIELD_TRANSFER_ENCODING,
> MIME_LEN_TRANSFER_ENCODING);
> ...
> 5792 while (enc_value) {
> 5793const char *wks_value = hdrtoken_string_to_wks(enc_value,
> enc_val_len);
> 5794
> 5795// FIX ME: What is chunked appears more than once? Old
> 5796// code didn't deal with this so I don't either
> 5797if (wks_value == HTTP_VALUE_CHUNKED) {
> ...
> 5813 // Loop over the all the values in existing Trans-enc header
> and
> 5814 // copy the ones that aren't our chunked value to a new
> field
> 5815 while (new_enc_val) {
> 5816
[jira] [Comment Edited] (TS-2743) SPDY_ATS - Crash with SPDY on production environment in SpdyNV::SpdyNV
[
https://issues.apache.org/jira/browse/TS-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979064#comment-13979064
]
Sudheer Vinukonda edited comment on TS-2743 at 4/23/14 11:34 PM:
-
It looks like the code may have an issue. There may be non string type http
headers (e.g Expires), which will fail the assert.
SpdyNV::SpdyNV(TSFetchSM fetch_sm)
{
//
//...
value = TSMimeHdrFieldValueStringGet(bufp, loc, field_loc, -1, &value_len);
TSReleaseAssert(value && value_len);
//
To confirm, did a simple test by replacing the assert with an error log and
noticed the below errors coming out a lot and the core dump looks to be fixed
(although, a new core dump occured - will open a separate jira for that). Will
be trying a patch to try TSMimeHdrFieldValueDateGet() if the
TSMimeHdrFieldValueStringGet() fails or may be just replace
TSMimeHdrFieldValueStringGet() with TSMimeHdrFieldValueGet()
20140423.23h05m42s Spdy Error in processing hdr Expires of field length 7
was (Author: sudheerv):
It looks like the code may have an issue. There may be non string type http
headers (e.g Expires), which will fail the assert.
SpdyNV::SpdyNV(TSFetchSM fetch_sm)
{
//
//...
value = TSMimeHdrFieldValueStringGet(bufp, loc, field_loc, -1, &value_len);
TSReleaseAssert(value && value_len);
//
To confirm, did a simple test by replacing the assert with an error log and
noticed the below errors coming out a lot and the core dump looks to be fixed
(although, a new core dump occured - will open a separate jira for that). Will
be trying a patch to try TSMimeHdrFieldValueDateGet() if the
TSMimeHdrFieldValueStringGet() fails.
20140423.23h05m42s Spdy Error in processing hdr Expires of field length 7
> SPDY_ATS - Crash with SPDY on production environment in SpdyNV::SpdyNV
> --
>
> Key: TS-2743
> URL: https://issues.apache.org/jira/browse/TS-2743
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Sudheer Vinukonda
>
> After patching a fix (by removing the apparent incorrect assert failure on
> non-ipv4 address in TsFetchCreate - jira ts-2742), noticed a new crash, this
> time in SpdyNV::SpdyNV with the below stack trace. Will update more upon
> investigation.
> FATAL: SpdyCommon.cc:133: failed assert `value && value_len`
> FATAL: SpdyCommon.cc:133: failed assert `value && value_len`
> /home/y/bin/traffic_server - STACK TRACE:
> /home/y/bin/traffic_server - STACK TRACE:
> /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b7371f6a5c8]
> /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b7371f6a5c8]
> /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b7371f68a8f]
> /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b7371f68a8f]
> /home/y/bin/traffic_server[0x4af739]
> /home/y/bin/traffic_server[0x5cf7ea]
> /home/y/bin/traffic_server[0x5d0a6a]
> /home/y/bin/traffic_server(_ZN7FetchSM15InvokePluginExtEi+0x33a)[0x4c7a5a]
> /home/y/bin/traffic_server[0x4af739]
> /home/y/bin/traffic_server(_ZN7FetchSM18process_fetch_readEi+0x187)[0x4c7f37]
> /home/y/bin/traffic_server[0x5cf7ea]
> /home/y/bin/traffic_server[0x5d0a6a]
> /home/y/bin/traffic_server(_ZN7FetchSM15InvokePluginExtEi+0x33a)[0x4c7a5a]
> /home/y/bin/traffic_server(_ZN7FetchSM18process_fetch_readEi+0x187)[0x4c7f37]
> /home/y/bin/traffic_server(_ZN7FetchSM13fetch_handlerEiPv+0x8b)[0x4c80eb]
> /home/y/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x375)[0x4dd0d5]
> /home/y/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x57a)[0x4dda2a]
> /home/y/bin/traffic_server(_ZN7FetchSM13fetch_handlerEiPv+0x8b)[0x4c80eb]
> /home/y/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x372)[0x4de272]
> /home/y/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x375)[0x4dd0d5]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f7f]
> /home/y/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x57a)[0x4dda2a]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x713aab]
> /home/y/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x372)[0x4de272]
> /home/y/bin/traffic_server[0x71232a]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f7f]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b7372601851]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x713aab]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
> /home/y/bin/traffic_server[0x71232a]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b7372601851]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2743) SPDY_ATS - Crash with SPDY on production environment in SpdyNV::SpdyNV
[
https://issues.apache.org/jira/browse/TS-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979064#comment-13979064
]
Sudheer Vinukonda edited comment on TS-2743 at 4/23/14 11:40 PM:
-
It looks like the code may have an issue. There may be non string type http
headers (e.g Expires), which will fail the assert.
SpdyNV::SpdyNV(TSFetchSM fetch_sm)
{
//
//...
value = TSMimeHdrFieldValueStringGet(bufp, loc, field_loc, -1, &value_len);
TSReleaseAssert(value && value_len);
//
To confirm, did a simple test by replacing the assert with an error log and
noticed the below errors coming out a lot and the core dump looks to be fixed
(although, a new core dump occured - will open a separate jira for that). Will
be trying a patch to try TSMimeHdrFieldValueDateGet() if the
TSMimeHdrFieldValueStringGet() fails or may be just replace
TSMimeHdrFieldValueStringGet() with TSMimeFieldValueGet()
20140423.23h05m42s Spdy Error in processing hdr Expires of field length 7
was (Author: sudheerv):
It looks like the code may have an issue. There may be non string type http
headers (e.g Expires), which will fail the assert.
SpdyNV::SpdyNV(TSFetchSM fetch_sm)
{
//
//...
value = TSMimeHdrFieldValueStringGet(bufp, loc, field_loc, -1, &value_len);
TSReleaseAssert(value && value_len);
//
To confirm, did a simple test by replacing the assert with an error log and
noticed the below errors coming out a lot and the core dump looks to be fixed
(although, a new core dump occured - will open a separate jira for that). Will
be trying a patch to try TSMimeHdrFieldValueDateGet() if the
TSMimeHdrFieldValueStringGet() fails or may be just replace
TSMimeHdrFieldValueStringGet() with TSMimeHdrFieldValueGet()
20140423.23h05m42s Spdy Error in processing hdr Expires of field length 7
> SPDY_ATS - Crash with SPDY on production environment in SpdyNV::SpdyNV
> --
>
> Key: TS-2743
> URL: https://issues.apache.org/jira/browse/TS-2743
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Sudheer Vinukonda
>
> After patching a fix (by removing the apparent incorrect assert failure on
> non-ipv4 address in TsFetchCreate - jira ts-2742), noticed a new crash, this
> time in SpdyNV::SpdyNV with the below stack trace. Will update more upon
> investigation.
> FATAL: SpdyCommon.cc:133: failed assert `value && value_len`
> FATAL: SpdyCommon.cc:133: failed assert `value && value_len`
> /home/y/bin/traffic_server - STACK TRACE:
> /home/y/bin/traffic_server - STACK TRACE:
> /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b7371f6a5c8]
> /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b7371f6a5c8]
> /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b7371f68a8f]
> /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b7371f68a8f]
> /home/y/bin/traffic_server[0x4af739]
> /home/y/bin/traffic_server[0x5cf7ea]
> /home/y/bin/traffic_server[0x5d0a6a]
> /home/y/bin/traffic_server(_ZN7FetchSM15InvokePluginExtEi+0x33a)[0x4c7a5a]
> /home/y/bin/traffic_server[0x4af739]
> /home/y/bin/traffic_server(_ZN7FetchSM18process_fetch_readEi+0x187)[0x4c7f37]
> /home/y/bin/traffic_server[0x5cf7ea]
> /home/y/bin/traffic_server[0x5d0a6a]
> /home/y/bin/traffic_server(_ZN7FetchSM15InvokePluginExtEi+0x33a)[0x4c7a5a]
> /home/y/bin/traffic_server(_ZN7FetchSM18process_fetch_readEi+0x187)[0x4c7f37]
> /home/y/bin/traffic_server(_ZN7FetchSM13fetch_handlerEiPv+0x8b)[0x4c80eb]
> /home/y/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x375)[0x4dd0d5]
> /home/y/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x57a)[0x4dda2a]
> /home/y/bin/traffic_server(_ZN7FetchSM13fetch_handlerEiPv+0x8b)[0x4c80eb]
> /home/y/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x372)[0x4de272]
> /home/y/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x375)[0x4dd0d5]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f7f]
> /home/y/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x57a)[0x4dda2a]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x713aab]
> /home/y/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x372)[0x4de272]
> /home/y/bin/traffic_server[0x71232a]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f7f]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b7372601851]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x713aab]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
> /home/y/bin/traffic_server[0x71232a]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b7372601851]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2744) TSNetAcceptNamedProtocol asserts for unknown protocols
James Peach created TS-2744:
---
Summary: TSNetAcceptNamedProtocol asserts for unknown protocols
Key: TS-2744
URL: https://issues.apache.org/jira/browse/TS-2744
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: James Peach
{{TSNetAcceptNamedProtocol}} is supposed to accept arbitrary strings because it
lets you implement your own protocol plugin over TLS, using NPN or ALPN to
demux the session. TS-2431 broke this by adding an assertion to
{{SSLNextProtocolSet::NextProtocolEndpoint::NextProtocolEndpoint}} when an
unknown protocol is registered. A large part of the point of this API is to
allow you to register your own protocol.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2744) TSNetAcceptNamedProtocol asserts for unknown protocols
[
https://issues.apache.org/jira/browse/TS-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979102#comment-13979102
]
James Peach commented on TS-2744:
-
There's no "unknown" value in {{TSProtoType}}, but I think it should be safe to
mark unrecognized protocols as {{TS_PROTO_TLS}}.
> TSNetAcceptNamedProtocol asserts for unknown protocols
> --
>
> Key: TS-2744
> URL: https://issues.apache.org/jira/browse/TS-2744
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Reporter: James Peach
>
> {{TSNetAcceptNamedProtocol}} is supposed to accept arbitrary strings because
> it lets you implement your own protocol plugin over TLS, using NPN or ALPN to
> demux the session. TS-2431 broke this by adding an assertion to
> {{SSLNextProtocolSet::NextProtocolEndpoint::NextProtocolEndpoint}} when an
> unknown protocol is registered. A large part of the point of this API is to
> allow you to register your own protocol.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2743) SPDY_ATS - Crash with SPDY on production environment in SpdyNV::SpdyNV
[ https://issues.apache.org/jira/browse/TS-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979107#comment-13979107 ] James Peach commented on TS-2743: - This code should all be using the internal APIs, not the external TS API. I don't know whether there's any point fixing these find of bugs. > SPDY_ATS - Crash with SPDY on production environment in SpdyNV::SpdyNV > -- > > Key: TS-2743 > URL: https://issues.apache.org/jira/browse/TS-2743 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Sudheer Vinukonda > > After patching a fix (by removing the apparent incorrect assert failure on > non-ipv4 address in TsFetchCreate - jira ts-2742), noticed a new crash, this > time in SpdyNV::SpdyNV with the below stack trace. Will update more upon > investigation. > FATAL: SpdyCommon.cc:133: failed assert `value && value_len` > FATAL: SpdyCommon.cc:133: failed assert `value && value_len` > /home/y/bin/traffic_server - STACK TRACE: > /home/y/bin/traffic_server - STACK TRACE: > /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b7371f6a5c8] > /home/y/lib64/libtsutil.so.5(+0x1f5c8)[0x2b7371f6a5c8] > /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b7371f68a8f] > /home/y/lib64/libtsutil.so.5(+0x1da8f)[0x2b7371f68a8f] > /home/y/bin/traffic_server[0x4af739] > /home/y/bin/traffic_server[0x5cf7ea] > /home/y/bin/traffic_server[0x5d0a6a] > /home/y/bin/traffic_server(_ZN7FetchSM15InvokePluginExtEi+0x33a)[0x4c7a5a] > /home/y/bin/traffic_server[0x4af739] > /home/y/bin/traffic_server(_ZN7FetchSM18process_fetch_readEi+0x187)[0x4c7f37] > /home/y/bin/traffic_server[0x5cf7ea] > /home/y/bin/traffic_server[0x5d0a6a] > /home/y/bin/traffic_server(_ZN7FetchSM15InvokePluginExtEi+0x33a)[0x4c7a5a] > /home/y/bin/traffic_server(_ZN7FetchSM18process_fetch_readEi+0x187)[0x4c7f37] > /home/y/bin/traffic_server(_ZN7FetchSM13fetch_handlerEiPv+0x8b)[0x4c80eb] > /home/y/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x375)[0x4dd0d5] > /home/y/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x57a)[0x4dda2a] > /home/y/bin/traffic_server(_ZN7FetchSM13fetch_handlerEiPv+0x8b)[0x4c80eb] > /home/y/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x372)[0x4de272] > /home/y/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x375)[0x4dd0d5] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f7f] > /home/y/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x57a)[0x4dda2a] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x713aab] > /home/y/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x372)[0x4de272] > /home/y/bin/traffic_server[0x71232a] > /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712f7f] > /lib64/libpthread.so.0(+0x3297207851)[0x2b7372601851] > /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x61b)[0x713aab] > /lib64/libc.so.6(clone+0x6d)[0x3296ee890d] > /home/y/bin/traffic_server[0x71232a] > /lib64/libpthread.so.0(+0x3297207851)[0x2b7372601851] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2744) TSNetAcceptNamedProtocol asserts for unknown protocols
[
https://issues.apache.org/jira/browse/TS-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned TS-2744:
---
Assignee: James Peach
> TSNetAcceptNamedProtocol asserts for unknown protocols
> --
>
> Key: TS-2744
> URL: https://issues.apache.org/jira/browse/TS-2744
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> {{TSNetAcceptNamedProtocol}} is supposed to accept arbitrary strings because
> it lets you implement your own protocol plugin over TLS, using NPN or ALPN to
> demux the session. TS-2431 broke this by adding an assertion to
> {{SSLNextProtocolSet::NextProtocolEndpoint::NextProtocolEndpoint}} when an
> unknown protocol is registered. A large part of the point of this API is to
> allow you to register your own protocol.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2744) TSNetAcceptNamedProtocol asserts for unknown protocols
[
https://issues.apache.org/jira/browse/TS-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2744:
Fix Version/s: 5.0.0
> TSNetAcceptNamedProtocol asserts for unknown protocols
> --
>
> Key: TS-2744
> URL: https://issues.apache.org/jira/browse/TS-2744
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> {{TSNetAcceptNamedProtocol}} is supposed to accept arbitrary strings because
> it lets you implement your own protocol plugin over TLS, using NPN or ALPN to
> demux the session. TS-2431 broke this by adding an assertion to
> {{SSLNextProtocolSet::NextProtocolEndpoint::NextProtocolEndpoint}} when an
> unknown protocol is registered. A large part of the point of this API is to
> allow you to register your own protocol.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2745) TSNetAcceptNamedProtocol should not unregister on error
James Peach created TS-2745:
---
Summary: TSNetAcceptNamedProtocol should not unregister on error
Key: TS-2745
URL: https://issues.apache.org/jira/browse/TS-2745
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: James Peach
{{TSNetAcceptNamedProtocol}} unregisters the names protocol if there's a
registration error. The most likely error is that the names protocol is already
registered, so this would cause it to get unregistered, which seems bad.
I'm not sure how to deal with protocols that are registered by the core;
currently a plugin could not override that registration. Maybe that's OK.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2746) undo accept continuation renaming
James Peach created TS-2746: --- Summary: undo accept continuation renaming Key: TS-2746 URL: https://issues.apache.org/jira/browse/TS-2746 Project: Traffic Server Issue Type: Bug Components: Cleanup Reporter: James Peach In TS-2341, all the FooAccept handlers were renamed to FooAcceptCont. If we added the Cont suffix to everything that was a continuation, there would be no other suffixes. We should undo this, or find a new naming convention. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2746) undo accept continuation renaming
[ https://issues.apache.org/jira/browse/TS-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2746: Description: In TS-2431, all the FooAccept handlers were renamed to FooAcceptCont. If we added the Cont suffix to everything that was a continuation, there would be no other suffixes. We should undo this, or find a new naming convention. (was: In TS-2341, all the FooAccept handlers were renamed to FooAcceptCont. If we added the Cont suffix to everything that was a continuation, there would be no other suffixes. We should undo this, or find a new naming convention.) > undo accept continuation renaming > - > > Key: TS-2746 > URL: https://issues.apache.org/jira/browse/TS-2746 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Reporter: James Peach > > In TS-2431, all the FooAccept handlers were renamed to FooAcceptCont. If we > added the Cont suffix to everything that was a continuation, there would be > no other suffixes. We should undo this, or find a new naming convention. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2433) Size threshold for SSL request
[ https://issues.apache.org/jira/browse/TS-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979250#comment-13979250 ] Wei Sun commented on TS-2433: - Apologize for not being able to proceed this (busy with other stuff). The original requirement comes from a very old patch for stunnel from my side, IMO, that's a rough throttling without distinguishing request header and body, perhaps since stunnel doesn't handle http sm. I'll try to see if it is still a strong needs from customers when using ats, and re-create a general patch if necessary. > Size threshold for SSL request > -- > > Key: TS-2433 > URL: https://issues.apache.org/jira/browse/TS-2433 > Project: Traffic Server > Issue Type: Task > Components: SSL >Reporter: Wei Sun >Assignee: Wei Sun > Labels: Review > Fix For: 5.0.0 > > Attachments: TS-2433.diff > > > A size threshold is expected for client request over SSL, if the max > requested data(SSL_read) exceeds the threshold, close the connection. > Default: no size limitation. We have this use case when using stunnel, expect > to have the same functionality in ATS. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2729) Add HTTP/2 support to ATS
[
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979277#comment-13979277
]
James Peach commented on TS-2729:
-
I started taking a closer look at this, and I can see that you have followed
the example of SPDY. Unfortunately, SPDY is currently a bad example; it still
needs significant amounts of work to move from the TS API on to the internal
API; the protocol probe mechanism needs work; the configuration needs work.
There's no tests for any of this. Sorry, but I'd rather not merge this in it's
current state.
> Add HTTP/2 support to ATS
> -
>
> Key: TS-2729
> URL: https://issues.apache.org/jira/browse/TS-2729
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP/2
>Reporter: Ryo OKUBO
> Labels: review
> Fix For: 5.0.0
>
> Attachments: draft11.patch, http2-0001.patch
>
>
> h2. Overview
> We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core
> experimentally.
> Now, it supports HTTP/2 draft-10.
> http://tools.ietf.org/html/draft-ietf-httpbis-http2-10
> Our implementation similar to the SPDY implementation in ATS core(TS-2431)
> but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
> https://github.com/tatsuhiro-t/nghttp2
> We tested NPN and ALPN negotiation.
> h2. How to test it
> * Install nghttp2 library, here is URL of this library:
> https://github.com/tatsuhiro-t/nghttp2
> * Use '--enable-http2' option to compile ATS:
> {noformat}
> $ ./configure --enable-http2
> $ make all && make install
> {noformat}
> * You can use '--with-openssl=' option.
> * Need not configure anything if you just want to test HTTP/2 without SSL.
> The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of
> requests.
> * You can use nghttp in nghttp2 library(or other HTTP/2 client) to request,
> for example:
> {noformat}
> # HTTP/2 without SSL
> $ nghttp -v http://localhost/b.txt
> # HTTP/2 + SSL
> $ nghttp -v https://localhost/b.txt
> {noformat}
> h2. TODO
> * Cleanup codes.
> * Follow http2 draft-12 and later.
> * -Support ALPN.-
> * Add settings related to HTTP/2 into records.config.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2746) undo accept continuation renaming
[
https://issues.apache.org/jira/browse/TS-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979310#comment-13979310
]
James Peach commented on TS-2746:
-
I think that "SessionAccept" is a reasonably descriptive name, so I propose
HttpAcceptCont -> HttpSessionAccept
SpdyAcceptCont -> SpdySessionAccept
ProtocolAcceptCont -> ProtocolDetectSessionAccept
I don't think that {{AcceptCont::createNetAccept}} is needed; the processor has
an equivalent virtual function that creates the correct kind of {{NetAccept}}.
> undo accept continuation renaming
> -
>
> Key: TS-2746
> URL: https://issues.apache.org/jira/browse/TS-2746
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup
>Reporter: James Peach
>
> In TS-2431, all the FooAccept handlers were renamed to FooAcceptCont. If we
> added the Cont suffix to everything that was a continuation, there would be
> no other suffixes. We should undo this, or find a new naming convention.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2746) undo accept continuation renaming
[ https://issues.apache.org/jira/browse/TS-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2746: Fix Version/s: 5.0.0 Assignee: James Peach > undo accept continuation renaming > - > > Key: TS-2746 > URL: https://issues.apache.org/jira/browse/TS-2746 > Project: Traffic Server > Issue Type: Bug > Components: Cleanup >Reporter: James Peach >Assignee: James Peach > Fix For: 5.0.0 > > > In TS-2431, all the FooAccept handlers were renamed to FooAcceptCont. If we > added the Cont suffix to everything that was a continuation, there would be > no other suffixes. We should undo this, or find a new naming convention. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2747) Segmentation fault,after update 4.1.2 to 4.2.0
acache created TS-2747: -- Summary: Segmentation fault,after update 4.1.2 to 4.2.0 Key: TS-2747 URL: https://issues.apache.org/jira/browse/TS-2747 Project: Traffic Server Issue Type: Bug Components: MIME Reporter: acache [TrafficServer] using root directory '/usr' NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2ba44394a500] /usr/bin/traffic_server(HttpTransactHeaders::insert_via_header_in_response(HttpTransact::State*, HTTPHdr*)+0x1b3)[0x564c43] /usr/bin/traffic_server(HttpTransact::build_response(HttpTransact::State*, HTTPHdr*, HTTPHdr*, HTTPVersion, HTTPStatus, char const*)+0x21b)[0x544a9b] /usr/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*, HTTPWarningCode)+0x354)[0x558784] /usr/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x448)[0x55a438] /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void (*)(HttpTransact::State*))+0x66)[0x515eb6] /usr/bin/traffic_server(HttpSM::handle_api_return()+0x37a)[0x52ee7a] /usr/bin/traffic_server(HttpSM::set_next_state()+0x1f2)[0x52f412] /usr/bin/traffic_server(HttpSM::handle_api_return()+0x37a)[0x52ee7a] /usr/bin/traffic_server(HttpSM::set_next_state()+0x1f2)[0x52f412] /usr/bin/traffic_server(HttpSM::state_cache_open_read(int, void*)+0xfe)[0x5237ae] /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5262c8] /usr/bin/traffic_server(HttpCacheSM::state_cache_open_read(int, void*)+0x1b2)[0x509a02] /usr/bin/traffic_server(CacheVC::callcont(int)+0x53)[0x5ef183] /usr/bin/traffic_server(CacheVC::openReadStartEarliest(int, Event*)+0x69b)[0x658b4b] /usr/bin/traffic_server(CacheVC::handleReadDone(int, Event*)+0x1ed)[0x638d1d] /usr/bin/traffic_server(AIOCallbackInternal::io_complete(int, void*)+0x35)[0x5ef3e5] /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6ab21f] /usr/bin/traffic_server(EThread::execute()+0x58b)[0x6abb9b] /usr/bin/traffic_server[0x6aa5aa] /lib64/libpthread.so.0(+0x7851)[0x2ba443942851] /lib64/libc.so.6(clone+0x6d)[0x2ba44493894d] -- This message was sent by Atlassian JIRA (v6.2#6252)
