[jira] [Comment Edited] (TS-3078) MIMEHdrImpl::unmarshal crash caused by cache corruption
[
https://issues.apache.org/jira/browse/TS-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152848#comment-14152848
]
kang li edited comment on TS-3078 at 9/30/14 6:29 AM:
--
This was turn out of a hardware issue. The disk is a old SSD disk have no ECC
mechanism.
>From the core dump Doc heap memory, that seems some filed in the HttpHdr
>metadata was changed. So it pointed to an invalid address, then cause the
>coredump. But if
{code}
proxy.config.cache.enable_checksum
{code}
was enabled. ATS can tolerant the disk error. But in the diags.log there would
be some warning log of the checksum error and magic check error.
There are also coredump message like this:
{code}
#0 0x0034cfc32925 in raise () from /lib64/libc.so.6
#1 0x0034cfc34105 in abort () from /lib64/libc.so.6
#2 0x2b726c052ce9 in ink_die_die_die (retval=15745) at ink_error.cc:43
#3 0x2b726c052f13 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=,
ap=0x2b726f442ad0)
at ink_error.cc:65
#4 0x2b726c053048 in ink_fatal (return_code=15745, message_format=0x3d87
) at ink_error.cc:73
#5 0x2b726c05152f in _ink_assert (expression=0x0, file=0x6 , line=-1) at ink_assert.cc:37
#6 0x005b4c19 in HdrHeap::unmarshal (this=0x2b72d7bf89f0,
buf_length=, obj_type=,
found_obj=,
block_ref=) at HdrHeap.cc:880
#7 0x005b8c32 in HTTPInfo::unmarshal (buf=0x2b72d7bf8048
"\355\336\315\253", len=1056, block_ref=0x2b72a0105d00) at HTTP.cc:1962
#8 0x00635e43 in unmarshal_helper (this=0x2b72f8044f10, event=, e=) at Cache.cc:2066
#9 CacheVC::handleReadDone (this=0x2b72f8044f10, event=,
e=) at Cache.cc:2195
#10 0x005f1845 in handleEvent (this=, event=, data=)
at ../../iocore/eventsystem/I_Continuation.h:146
#11 AIOCallbackInternal::io_complete (this=, event=, data=) at ../../iocore/aio/P_AIO.h:123
#12 0x006a990f in handleEvent (this=0x2b726dc2c010, e=0x2b728415c110,
calling_code=1) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b726dc2c010, e=0x2b728415c110,
calling_code=1) at UnixEThread.cc:141
#14 0x006aa48b in EThread::execute (this=0x2b726dc2c010) at
UnixEThread.cc:192
#15 0x006a87aa in spawn_thread_internal (a=0x2229050) at Thread.cc:88
#16 0x2b726c5d59d1 in start_thread () from /lib64/libpthread.so.0
#17 0x0034cfce8b6d in clone () from /lib64/libc.so.6
{code}
was (Author: kang li):
This was turn out of a hardware issue. The disk is a old SSD disk.
>From the core dump Doc heap memory, that seems some filed in the HttpHdr
>metadata was changed. So it pointed to an invalid address, then cause the
>coredump. But if
{code}
proxy.config.cache.enable_checksum
{code}
was enabled. ATS can tolerant the disk error. But in the diags.log there would
be some warning log of the checksum error and magic check error.
There are also coredump message like this:
{code}
#0 0x0034cfc32925 in raise () from /lib64/libc.so.6
#1 0x0034cfc34105 in abort () from /lib64/libc.so.6
#2 0x2b726c052ce9 in ink_die_die_die (retval=15745) at ink_error.cc:43
#3 0x2b726c052f13 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=,
ap=0x2b726f442ad0)
at ink_error.cc:65
#4 0x2b726c053048 in ink_fatal (return_code=15745, message_format=0x3d87
) at ink_error.cc:73
#5 0x2b726c05152f in _ink_assert (expression=0x0, file=0x6 , line=-1) at ink_assert.cc:37
#6 0x005b4c19 in HdrHeap::unmarshal (this=0x2b72d7bf89f0,
buf_length=, obj_type=,
found_obj=,
block_ref=) at HdrHeap.cc:880
#7 0x005b8c32 in HTTPInfo::unmarshal (buf=0x2b72d7bf8048
"\355\336\315\253", len=1056, block_ref=0x2b72a0105d00) at HTTP.cc:1962
#8 0x00635e43 in unmarshal_helper (this=0x2b72f8044f10, event=, e=) at Cache.cc:2066
#9 CacheVC::handleReadDone (this=0x2b72f8044f10, event=,
e=) at Cache.cc:2195
#10 0x005f1845 in handleEvent (this=, event=, data=)
at ../../iocore/eventsystem/I_Continuation.h:146
#11 AIOCallbackInternal::io_complete (this=, event=, data=) at ../../iocore/aio/P_AIO.h:123
#12 0x006a990f in handleEvent (this=0x2b726dc2c010, e=0x2b728415c110,
calling_code=1) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b726dc2c010, e=0x2b728415c110,
calling_code=1) at UnixEThread.cc:141
#14 0x006aa48b in EThread::execute (this=0x2b726dc2c010) at
UnixEThread.cc:192
#15 0x006a87aa in spawn_thread_internal (a=0x2229050) at Thread.cc:88
#16 0x2b726c5d59d1 in start_thread () from /lib64/libpthread.so.0
#17 0x0034cfce8b6d in clone () from /lib64/libc.so.6
{code}
> MIMEHdrImpl::unmarshal crash caused by cache corruption
> ---
>
> Key: TS-3078
> URL: https://issues.apache.org/jira/browse/TS
[jira] [Resolved] (TS-3078) MIMEHdrImpl::unmarshal crash caused by cache corruption
[
https://issues.apache.org/jira/browse/TS-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kang li resolved TS-3078.
-
Resolution: Fixed
After the disk replaced the problem resolved.
> MIMEHdrImpl::unmarshal crash caused by cache corruption
> ---
>
> Key: TS-3078
> URL: https://issues.apache.org/jira/browse/TS-3078
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, MIME
>Affects Versions: 4.0.2
>Reporter: kang li
> Labels: crash
> Fix For: 5.2.0
>
>
> {code}
> (gdb) bt
> #0 0x005c22c6 in unmarshal (this=0x2aaed05f61f8,
> offset=46930308587840) at MIME.cc:3534
> #1 MIMEHdrImpl::unmarshal (this=0x2aaed05f61f8, offset=46930308587840) at
> MIME.cc:3590
> #2 0x005b4bcb in HdrHeap::unmarshal (this=0x2aaed05f6140,
> buf_length=, obj_type=,
> found_obj=,
> block_ref=) at HdrHeap.cc:926
> #3 0x005b8be1 in HTTPInfo::unmarshal (buf=0x2aaed05f6048
> "\355\336\315\253", len=3280, block_ref=0x2aae080feec0) at HTTP.cc:1948
> #4 0x00635e43 in unmarshal_helper (this=0x2aae10081b90, event= optimized out>, e=) at Cache.cc:2066
> #5 CacheVC::handleReadDone (this=0x2aae10081b90, event= out>, e=) at Cache.cc:2195
> #6 0x005f1845 in handleEvent (this=,
> event=, data=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #7 AIOCallbackInternal::io_complete (this=,
> event=, data=) at
> ../../iocore/aio/P_AIO.h:123
> #8 0x006a990f in handleEvent (this=0x2aadf0809010, e=0x2aae3812b710,
> calling_code=1) at I_Continuation.h:146
> #9 EThread::process_event (this=0x2aadf0809010, e=0x2aae3812b710,
> calling_code=1) at UnixEThread.cc:141
> #10 0x006aa48b in EThread::execute (this=0x2aadf0809010) at
> UnixEThread.cc:192
> #11 0x006a87aa in spawn_thread_internal (a=0x13e0a80) at Thread.cc:88
> #12 0x2aadeaf3c9d1 in start_thread () from /lib64/libpthread.so.0
> #13 0x0034cfce8b6d in clone () from /lib64/libc.so.6
> (gdb) p m_freetop
> $1 = 892220471
> (gdb) p m_field_slots
> $2 = {{m_ptr_name = 0x33203a2274616c22 bounds>, m_ptr_value = 0x393938312e33 bounds>,
> m_next_dup = 0x3a226e6f6c22202c, m_wks_idx = 11552, m_len_name = 14137,
> m_len_value = 3289390, m_n_v_raw_printable = 0 '\000',
> m_n_v_raw_printable_pad = 3 '\003',
> m_readiness = 3 '\003', m_flags = 0 '\000'}, {m_ptr_name =
> 0x766c4ccefc939174 ,
> m_ptr_value = 0x222056def09983ac bounds>, m_next_dup = 0x203a4d1444c0d5b3, m_wks_idx = 21538, m_len_name =
> 9048,
> m_len_value = 7890260, m_n_v_raw_printable = 1 '\001',
> m_n_v_raw_printable_pad = 0 '\000', m_readiness = 2 '\002', m_flags = 1
> '\001'}, {
> m_ptr_name = 0x656f7722202c2273 bounds>, m_ptr_value = 0x3039373231203a22 bounds>,
> m_next_dup = 0x697a22202c393739, m_wks_idx = 8816, m_len_name = 8250,
> m_len_value = 3553058, m_n_v_raw_printable = 0 '\000',
> m_n_v_raw_printable_pad = 1 '\001',
> m_readiness = 3 '\003', m_flags = 0 '\000'}, {m_ptr_name =
> 0x7d5d4b2bf0819670 ,
> m_ptr_value = 0x796b8e1844d2836c bounds>, m_next_dup = 0x756c8c24f2da9b62, m_wks_idx = 8805, m_len_name =
> 31546,
> m_len_value = 7152160, m_n_v_raw_printable = 1 '\001',
> m_n_v_raw_printable_pad = 0 '\000', m_readiness = 2 '\002', m_flags = 1
> '\001'}, {
> m_ptr_name = 0x22207b203a227370 bounds>, m_ptr_value = 0x22203a2272646461 bounds>,
> m_next_dup = 0x626d452034323332, m_wks_idx = 29285, m_len_name = 22304,
> m_len_value = 6582127, m_n_v_raw_printable = 1 '\001',
> m_n_v_raw_printable_pad = 1 '\001',
> m_readiness = 3 '\003', m_flags = 1 '\001'}, {m_ptr_name =
> 0x6c654b202c724420 ,
> {code}
> This only happened in one machine in four nodes. The frequency is about
> several days one time. After disable plugins and restart ATS the problem
> still exist. And there are also some warning in traffic.out. One interesting
> thing is that the warning all happened "after 776 bytes".
> {code}
> WARNING: Unmarshal failed due to unknow obj type 173 after 776 bytes
> Dumping header heap @ 0x2b37b251e140 - len 2250 --
> 0x2b37b251e140: 0xdcbafeed 0x0 0xb251e4b8 0x2b37
> 0x2b37b251e150: 0xb251e1c8 0x2b37 0x378 0x0
> 0x2b37b251e160: 0x0 0x0 0x0 0x0
> 0x2b37b251e170: 0x0 0x0 0x956b2af0 0x2b39
> 0x2b37b251e180: 0xb251e4b8 0x2b37 0x552 0x312e312f
> 0x2b37b251e190: 0x31323420 0x63655220 0x0 0x0
> 0x2b37b251e1a0: 0xd646e75 0x6361430a 0x432d6568 0x72746e6f
> 0x2b37b251e1b0: 0x0 0x0 0xd657461 0x6e6f430a
> 0x2b37b251e1c0: 0x89 0x7079542d 0x3003 0x1
> 0x2b37b251e1d0: 0x10001 0x480004 0xb251e448 0x2b37
> 0x2b37b251e1e0: 0xb251e4b8 0x2b37 0x6e0003 0x0
> 0x2b37b251e1f0: 0xb251e1f8 0x2b37 0x25004 0x2b35
> 0x2b37b251e200: 0x1000401 0x0 0x6ff1 0xfffe
> 0x2b37b251e210: 0x 0xfeff 0x0 0x0
> 0x2b37b251e220: 0x0 0x0 0x0 0x2b00
> 0x
[jira] [Comment Edited] (TS-3078) MIMEHdrImpl::unmarshal crash caused by cache corruption
[
https://issues.apache.org/jira/browse/TS-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152848#comment-14152848
]
kang li edited comment on TS-3078 at 9/30/14 6:27 AM:
--
This was turn out of a hardware issue. The disk is a old SSD disk.
>From the core dump Doc heap memory, that seems some filed in the HttpHdr
>metadata was changed. So it pointed to an invalid address, then cause the
>coredump. But if
{code}
proxy.config.cache.enable_checksum
{code}
was enabled. ATS can tolerant the disk error. But in the diags.log there would
be some warning log of the checksum error and magic check error.
There are also coredump message like this:
{code}
#0 0x0034cfc32925 in raise () from /lib64/libc.so.6
#1 0x0034cfc34105 in abort () from /lib64/libc.so.6
#2 0x2b726c052ce9 in ink_die_die_die (retval=15745) at ink_error.cc:43
#3 0x2b726c052f13 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=,
ap=0x2b726f442ad0)
at ink_error.cc:65
#4 0x2b726c053048 in ink_fatal (return_code=15745, message_format=0x3d87
) at ink_error.cc:73
#5 0x2b726c05152f in _ink_assert (expression=0x0, file=0x6 , line=-1) at ink_assert.cc:37
#6 0x005b4c19 in HdrHeap::unmarshal (this=0x2b72d7bf89f0,
buf_length=, obj_type=,
found_obj=,
block_ref=) at HdrHeap.cc:880
#7 0x005b8c32 in HTTPInfo::unmarshal (buf=0x2b72d7bf8048
"\355\336\315\253", len=1056, block_ref=0x2b72a0105d00) at HTTP.cc:1962
#8 0x00635e43 in unmarshal_helper (this=0x2b72f8044f10, event=, e=) at Cache.cc:2066
#9 CacheVC::handleReadDone (this=0x2b72f8044f10, event=,
e=) at Cache.cc:2195
#10 0x005f1845 in handleEvent (this=, event=, data=)
at ../../iocore/eventsystem/I_Continuation.h:146
#11 AIOCallbackInternal::io_complete (this=, event=, data=) at ../../iocore/aio/P_AIO.h:123
#12 0x006a990f in handleEvent (this=0x2b726dc2c010, e=0x2b728415c110,
calling_code=1) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b726dc2c010, e=0x2b728415c110,
calling_code=1) at UnixEThread.cc:141
#14 0x006aa48b in EThread::execute (this=0x2b726dc2c010) at
UnixEThread.cc:192
#15 0x006a87aa in spawn_thread_internal (a=0x2229050) at Thread.cc:88
#16 0x2b726c5d59d1 in start_thread () from /lib64/libpthread.so.0
#17 0x0034cfce8b6d in clone () from /lib64/libc.so.6
{code}
was (Author: kang li):
This was turn out of a hardware issue. The disk is a old SSD disk.
>From the core dump Doc heap memory, that seems some filed in the HttpHdr
>metadata was changed. So it pointed to an invalid address, then cause the
>coredump. But if
{code}
proxy.config.cache.enable_checksum
{code}
was enabled. ATS can tolerant the disk error. But in the diags.log there would
be some warning log of the checksum error and magic check error.
There are also coredump message like this:
{code}
#0 0x0034cfc32925 in raise () from /lib64/libc.so.6
#1 0x0034cfc34105 in abort () from /lib64/libc.so.6
#2 0x2b726c052ce9 in ink_die_die_die (retval=15745) at ink_error.cc:43
#3 0x2b726c052f13 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=,
ap=0x2b726f442ad0)
at ink_error.cc:65
#4 0x2b726c053048 in ink_fatal (return_code=15745, message_format=0x3d87
) at ink_error.cc:73
#5 0x2b726c05152f in _ink_assert (expression=0x0, file=0x6 , line=-1) at ink_assert.cc:37
#6 0x005b4c19 in HdrHeap::unmarshal (this=0x2b72d7bf89f0,
buf_length=, obj_type=,
found_obj=,
block_ref=) at HdrHeap.cc:880
#7 0x005b8c32 in HTTPInfo::unmarshal (buf=0x2b72d7bf8048
"\355\336\315\253", len=1056, block_ref=0x2b72a0105d00) at HTTP.cc:1962
#8 0x00635e43 in unmarshal_helper (this=0x2b72f8044f10, event=, e=) at Cache.cc:2066
#9 CacheVC::handleReadDone (this=0x2b72f8044f10, event=,
e=) at Cache.cc:2195
#10 0x005f1845 in handleEvent (this=, event=, data=)
at ../../iocore/eventsystem/I_Continuation.h:146
#11 AIOCallbackInternal::io_complete (this=, event=, data=) at ../../iocore/aio/P_AIO.h:123
#12 0x006a990f in handleEvent (this=0x2b726dc2c010, e=0x2b728415c110,
calling_code=1) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b726dc2c010, e=0x2b728415c110,
calling_code=1) at UnixEThread.cc:141
#14 0x006aa48b in EThread::execute (this=0x2b726dc2c010) at
UnixEThread.cc:192
#15 0x006a87aa in spawn_thread_internal (a=0x2229050) at Thread.cc:88
#16 0x2b726c5d59d1 in start_thread () from /lib64/libpthread.so.0
#17 0x0034cfce8b6d in clone () from /lib64/libc.so.6
{code}
> MIMEHdrImpl::unmarshal crash caused by cache corruption
> ---
>
> Key: TS-3078
> URL: https://issues.apache.org/jira/browse/TS-3078
> Pro
[jira] [Commented] (TS-3078) MIMEHdrImpl::unmarshal crash caused by cache corruption
[
https://issues.apache.org/jira/browse/TS-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152848#comment-14152848
]
kang li commented on TS-3078:
-
This was turn out of a hardware issue. The disk is a old SSD disk.
>From the core dump Doc heap memory, that seems some filed in the HttpHdr
>metadata was changed. So it pointed to an invalid address, then cause the
>coredump. But if
{code}
proxy.config.cache.enable_checksum
{code}
was enabled. ATS can tolerant the disk error. But in the diags.log there would
be some warning log of the checksum error and magic check error.
There are also coredump message like this:
{code}
#0 0x0034cfc32925 in raise () from /lib64/libc.so.6
#1 0x0034cfc34105 in abort () from /lib64/libc.so.6
#2 0x2b726c052ce9 in ink_die_die_die (retval=15745) at ink_error.cc:43
#3 0x2b726c052f13 in ink_fatal_va(int, const char *, typedef __va_list_tag
__va_list_tag *) (return_code=1, message_format=,
ap=0x2b726f442ad0)
at ink_error.cc:65
#4 0x2b726c053048 in ink_fatal (return_code=15745, message_format=0x3d87
) at ink_error.cc:73
#5 0x2b726c05152f in _ink_assert (expression=0x0, file=0x6 , line=-1) at ink_assert.cc:37
#6 0x005b4c19 in HdrHeap::unmarshal (this=0x2b72d7bf89f0,
buf_length=, obj_type=,
found_obj=,
block_ref=) at HdrHeap.cc:880
#7 0x005b8c32 in HTTPInfo::unmarshal (buf=0x2b72d7bf8048
"\355\336\315\253", len=1056, block_ref=0x2b72a0105d00) at HTTP.cc:1962
#8 0x00635e43 in unmarshal_helper (this=0x2b72f8044f10, event=, e=) at Cache.cc:2066
#9 CacheVC::handleReadDone (this=0x2b72f8044f10, event=,
e=) at Cache.cc:2195
#10 0x005f1845 in handleEvent (this=, event=, data=)
at ../../iocore/eventsystem/I_Continuation.h:146
#11 AIOCallbackInternal::io_complete (this=, event=, data=) at ../../iocore/aio/P_AIO.h:123
#12 0x006a990f in handleEvent (this=0x2b726dc2c010, e=0x2b728415c110,
calling_code=1) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b726dc2c010, e=0x2b728415c110,
calling_code=1) at UnixEThread.cc:141
#14 0x006aa48b in EThread::execute (this=0x2b726dc2c010) at
UnixEThread.cc:192
#15 0x006a87aa in spawn_thread_internal (a=0x2229050) at Thread.cc:88
#16 0x2b726c5d59d1 in start_thread () from /lib64/libpthread.so.0
#17 0x0034cfce8b6d in clone () from /lib64/libc.so.6
{code}
> MIMEHdrImpl::unmarshal crash caused by cache corruption
> ---
>
> Key: TS-3078
> URL: https://issues.apache.org/jira/browse/TS-3078
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, MIME
>Affects Versions: 4.0.2
>Reporter: kang li
> Labels: crash
> Fix For: 5.2.0
>
>
> {code}
> (gdb) bt
> #0 0x005c22c6 in unmarshal (this=0x2aaed05f61f8,
> offset=46930308587840) at MIME.cc:3534
> #1 MIMEHdrImpl::unmarshal (this=0x2aaed05f61f8, offset=46930308587840) at
> MIME.cc:3590
> #2 0x005b4bcb in HdrHeap::unmarshal (this=0x2aaed05f6140,
> buf_length=, obj_type=,
> found_obj=,
> block_ref=) at HdrHeap.cc:926
> #3 0x005b8be1 in HTTPInfo::unmarshal (buf=0x2aaed05f6048
> "\355\336\315\253", len=3280, block_ref=0x2aae080feec0) at HTTP.cc:1948
> #4 0x00635e43 in unmarshal_helper (this=0x2aae10081b90, event= optimized out>, e=) at Cache.cc:2066
> #5 CacheVC::handleReadDone (this=0x2aae10081b90, event= out>, e=) at Cache.cc:2195
> #6 0x005f1845 in handleEvent (this=,
> event=, data=)
> at ../../iocore/eventsystem/I_Continuation.h:146
> #7 AIOCallbackInternal::io_complete (this=,
> event=, data=) at
> ../../iocore/aio/P_AIO.h:123
> #8 0x006a990f in handleEvent (this=0x2aadf0809010, e=0x2aae3812b710,
> calling_code=1) at I_Continuation.h:146
> #9 EThread::process_event (this=0x2aadf0809010, e=0x2aae3812b710,
> calling_code=1) at UnixEThread.cc:141
> #10 0x006aa48b in EThread::execute (this=0x2aadf0809010) at
> UnixEThread.cc:192
> #11 0x006a87aa in spawn_thread_internal (a=0x13e0a80) at Thread.cc:88
> #12 0x2aadeaf3c9d1 in start_thread () from /lib64/libpthread.so.0
> #13 0x0034cfce8b6d in clone () from /lib64/libc.so.6
> (gdb) p m_freetop
> $1 = 892220471
> (gdb) p m_field_slots
> $2 = {{m_ptr_name = 0x33203a2274616c22 bounds>, m_ptr_value = 0x393938312e33 bounds>,
> m_next_dup = 0x3a226e6f6c22202c, m_wks_idx = 11552, m_len_name = 14137,
> m_len_value = 3289390, m_n_v_raw_printable = 0 '\000',
> m_n_v_raw_printable_pad = 3 '\003',
> m_readiness = 3 '\003', m_flags = 0 '\000'}, {m_ptr_name =
> 0x766c4ccefc939174 ,
> m_ptr_value = 0x222056def09983ac bounds>, m_next_dup = 0x203a4d1444c0d5b3, m_wks_idx = 21538, m_len_name =
> 9048,
> m_len_value = 7890260, m_n_v_raw_printable = 1 '\001',
> m_n_v_raw_printable_pad = 0
[jira] [Commented] (TS-1435) return full content if client is a muti range request
[ https://issues.apache.org/jira/browse/TS-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152227#comment-14152227 ] William Bardwell commented on TS-1435: -- It looks like HttpSM::calculate_output_cl() just needs to stop adding in the content_length when doing multiple ranges. > return full content if client is a muti range request > - > > Key: TS-1435 > URL: https://issues.apache.org/jira/browse/TS-1435 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: weijin >Assignee: Alan M. Carroll > Fix For: 5.2.0 > > > if client request is a muti range, and served from the cache, it returns the > full content. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1435) return full content if client is a muti range request
[ https://issues.apache.org/jira/browse/TS-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151777#comment-14151777 ] William Bardwell commented on TS-1435: -- Oh no the Content-Length is the full content length for each section plus some more for what was actually sent... > return full content if client is a muti range request > - > > Key: TS-1435 > URL: https://issues.apache.org/jira/browse/TS-1435 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: weijin >Assignee: Alan M. Carroll > Fix For: 5.2.0 > > > if client request is a muti range, and served from the cache, it returns the > full content. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1435) return full content if client is a muti range request
[ https://issues.apache.org/jira/browse/TS-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151769#comment-14151769 ] William Bardwell commented on TS-1435: -- We are seeing this bug too, although it does not seem to send the whole response, rather it seems to send a reasonable looking body, but the full response Content-Length, which confuses the clients. > return full content if client is a muti range request > - > > Key: TS-1435 > URL: https://issues.apache.org/jira/browse/TS-1435 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: weijin >Assignee: Alan M. Carroll > Fix For: 5.2.0 > > > if client request is a muti range, and served from the cache, it returns the > full content. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
