[jira] [Work started] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode
[ https://issues.apache.org/jira/browse/TS-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-3817 started by Uri Shachar. --- > Assertion on non (HTTP/S WS/S) request scheme in debug mode > --- > > Key: TS-3817 > URL: https://issues.apache.org/jira/browse/TS-3817 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Uri Shachar >Assignee: Uri Shachar > > When responding to a known (but unhandled) scheme we assert in > HttpTransact::check_response_validity > FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == > URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS` > This is due to an incorrect check in check_request_validity (that was > supposed to catch and return an error on this condition) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode
[ https://issues.apache.org/jira/browse/TS-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar reassigned TS-3817: --- Assignee: Uri Shachar > Assertion on non (HTTP/S WS/S) request scheme in debug mode > --- > > Key: TS-3817 > URL: https://issues.apache.org/jira/browse/TS-3817 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Uri Shachar >Assignee: Uri Shachar > > When responding to a known (but unhandled) scheme we assert in > HttpTransact::check_response_validity > FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == > URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS` > This is due to an incorrect check in check_request_validity (that was > supposed to catch and return an error on this condition) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode
Uri Shachar created TS-3817: --- Summary: Assertion on non (HTTP/S WS/S) request scheme in debug mode Key: TS-3817 URL: https://issues.apache.org/jira/browse/TS-3817 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Uri Shachar When responding to a known (but unhandled) scheme we assert in HttpTransact::check_response_validity FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS` This is due to an incorrect check in check_request_validity (that was supposed to catch and return an error on this condition) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode
[ https://issues.apache.org/jira/browse/TS-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar resolved TS-3817. - Resolution: Fixed > Assertion on non (HTTP/S WS/S) request scheme in debug mode > --- > > Key: TS-3817 > URL: https://issues.apache.org/jira/browse/TS-3817 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Uri Shachar >Assignee: Uri Shachar > > When responding to a known (but unhandled) scheme we assert in > HttpTransact::check_response_validity > FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == > URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS` > This is due to an incorrect check in check_request_validity (that was > supposed to catch and return an error on this condition) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode
[ https://issues.apache.org/jira/browse/TS-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653778#comment-14653778 ] Uri Shachar commented on TS-3817: - [~zwoop] I think this should be merged into 6.0 > Assertion on non (HTTP/S WS/S) request scheme in debug mode > --- > > Key: TS-3817 > URL: https://issues.apache.org/jira/browse/TS-3817 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Uri Shachar >Assignee: Uri Shachar > > When responding to a known (but unhandled) scheme we assert in > HttpTransact::check_response_validity > FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == > URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS` > This is due to an incorrect check in check_request_validity (that was > supposed to catch and return an error on this condition) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4116) DNS failure prohibits use of client target address
[ https://issues.apache.org/jira/browse/TS-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar reassigned TS-4116: --- Assignee: Uri Shachar (was: Thomas Jackson) > DNS failure prohibits use of client target address > -- > > Key: TS-4116 > URL: https://issues.apache.org/jira/browse/TS-4116 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 5.3.2 >Reporter: Kalin Krastanov >Assignee: Uri Shachar > Fix For: sometime > > > When ATS is set up to use client target address in transparent mode and there > is DNS error (i.e. the OS name is resolvable only on the client machine) 502 > error is returned instead of using the client target address. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4116) DNS failure prohibits use of client target address
[ https://issues.apache.org/jira/browse/TS-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar resolved TS-4116. - Resolution: Done Fix Version/s: (was: sometime) 7.0.0 > DNS failure prohibits use of client target address > -- > > Key: TS-4116 > URL: https://issues.apache.org/jira/browse/TS-4116 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 5.3.2 >Reporter: Kalin Krastanov >Assignee: Uri Shachar > Fix For: 7.0.0 > > > When ATS is set up to use client target address in transparent mode and there > is DNS error (i.e. the OS name is resolvable only on the client machine) 502 > error is returned instead of using the client target address. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4511) ATS crashes when no_dns_just_forward is configured without parent proxies
Uri Shachar created TS-4511: --- Summary: ATS crashes when no_dns_just_forward is configured without parent proxies Key: TS-4511 URL: https://issues.apache.org/jira/browse/TS-4511 Project: Traffic Server Issue Type: Bug Components: DNS, Parent Proxy Reporter: Uri Shachar When ATS is configured with: CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1 (and parent routing is enabled) and a request comes in that does not have a parent defined for it in parent.config ATS will abort with the following backtrace: FATAL: HttpTransact.cc:7608: failed assertion `s->parent_result.result == PARENT_FAIL` ./bin/traffic_server(_ZN12HttpTransact18handle_parent_diedEPNS_5StateE+0x38)[0x6208fe] ./bin/traffic_server(_ZN12HttpTransact23HandleCacheOpenReadMissEPNS_5StateE+0x686)[0x60e868] ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x71)[0x5f118d] ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74] ./bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x40)[0x5f876a] ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x75)[0x5f1347] ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca] ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xb21)[0x5f1df3] ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca] ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4511) ATS crashes when no_dns_just_forward is configured without parent proxies
[ https://issues.apache.org/jira/browse/TS-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar reassigned TS-4511: --- Assignee: Uri Shachar > ATS crashes when no_dns_just_forward is configured without parent proxies > - > > Key: TS-4511 > URL: https://issues.apache.org/jira/browse/TS-4511 > Project: Traffic Server > Issue Type: Bug > Components: DNS, Parent Proxy >Reporter: Uri Shachar >Assignee: Uri Shachar > > When ATS is configured with: > CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1 > (and parent routing is enabled) > and a request comes in that does not have a parent defined for it in > parent.config ATS will abort with the following backtrace: > FATAL: HttpTransact.cc:7608: failed assertion `s->parent_result.result == > PARENT_FAIL` > ./bin/traffic_server(_ZN12HttpTransact18handle_parent_diedEPNS_5StateE+0x38)[0x6208fe] > ./bin/traffic_server(_ZN12HttpTransact23HandleCacheOpenReadMissEPNS_5StateE+0x686)[0x60e868] > ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x71)[0x5f118d] > ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74] > ./bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x40)[0x5f876a] > ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x75)[0x5f1347] > ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca] > ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xb21)[0x5f1df3] > ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca] > ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74] > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4511) ATS crashes when no_dns_just_forward is configured without parent proxies
[ https://issues.apache.org/jira/browse/TS-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318289#comment-15318289 ] Uri Shachar commented on TS-4511: - I get a completely different backtrace, but the root cause is probably the same. > ATS crashes when no_dns_just_forward is configured without parent proxies > - > > Key: TS-4511 > URL: https://issues.apache.org/jira/browse/TS-4511 > Project: Traffic Server > Issue Type: Bug > Components: DNS, Parent Proxy >Reporter: Uri Shachar >Assignee: Uri Shachar > > When ATS is configured with: > CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1 > (and parent routing is enabled) > and a request comes in that does not have a parent defined for it in > parent.config ATS will abort with the following backtrace: > FATAL: HttpTransact.cc:7608: failed assertion `s->parent_result.result == > PARENT_FAIL` > ./bin/traffic_server(_ZN12HttpTransact18handle_parent_diedEPNS_5StateE+0x38)[0x6208fe] > ./bin/traffic_server(_ZN12HttpTransact23HandleCacheOpenReadMissEPNS_5StateE+0x686)[0x60e868] > ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x71)[0x5f118d] > ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74] > ./bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x40)[0x5f876a] > ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x75)[0x5f1347] > ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca] > ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xb21)[0x5f1df3] > ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca] > ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74] > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3676) CONFIG proxy.config.http.no_dns_just_forward_to_parent triggers crash
[
https://issues.apache.org/jira/browse/TS-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318403#comment-15318403
]
Uri Shachar commented on TS-3676:
-
I haven't been able to reproduce the exact stacktrace here -- but I have fixed
something very similar.
Please reopen the issue if the linked fix doesn't resolve it.
> CONFIG proxy.config.http.no_dns_just_forward_to_parent triggers crash
> -
>
> Key: TS-3676
> URL: https://issues.apache.org/jira/browse/TS-3676
> Project: Traffic Server
> Issue Type: Bug
> Components: Parent Proxy
>Reporter: Randall Meyer
>Assignee: John Rushford
> Labels: A
> Fix For: 7.0.0
>
> Attachments: stacktrace.txt
>
>
> I have a parent/child cluster running without issue. Recently, I added a new
> map to a unresolvable name on the child host (in my example "resource_host").
> I set proxy.config.http.no_dns_just_forward_to_parent to 1 on the child.
> This worked fine for some time(many hours), serving up . But after awhile,
> the parent ATS-process crashes.
> 3 days later (with crashes happening every evening), I changed the config
> back to 0 and started using a name resolvable on the child. Since that
> change, there's been no crashes.
> This was observed on a set of 30 child hosts all dying with the same
> callstack.
> records.config:
> {noformat}
> CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
> CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
> {noformat}
> remap.config:
> {noformat}
> map /resource.json \
> http://resource_host/mapped/resource.json
> {noformat}
> parent.config
> {noformat}
> dest_domain=resource_host method=get parent="parent_host.domain.com:80"
> round_robin=consistent_hash go_direct=false
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-3676) CONFIG proxy.config.http.no_dns_just_forward_to_parent triggers crash
[
https://issues.apache.org/jira/browse/TS-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uri Shachar resolved TS-3676.
-
Resolution: Duplicate
Assignee: Randall Meyer (was: John Rushford)
> CONFIG proxy.config.http.no_dns_just_forward_to_parent triggers crash
> -
>
> Key: TS-3676
> URL: https://issues.apache.org/jira/browse/TS-3676
> Project: Traffic Server
> Issue Type: Bug
> Components: Parent Proxy
>Reporter: Randall Meyer
>Assignee: Randall Meyer
> Labels: A
> Fix For: 7.0.0
>
> Attachments: stacktrace.txt
>
>
> I have a parent/child cluster running without issue. Recently, I added a new
> map to a unresolvable name on the child host (in my example "resource_host").
> I set proxy.config.http.no_dns_just_forward_to_parent to 1 on the child.
> This worked fine for some time(many hours), serving up . But after awhile,
> the parent ATS-process crashes.
> 3 days later (with crashes happening every evening), I changed the config
> back to 0 and started using a name resolvable on the child. Since that
> change, there's been no crashes.
> This was observed on a set of 30 child hosts all dying with the same
> callstack.
> records.config:
> {noformat}
> CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
> CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
> {noformat}
> remap.config:
> {noformat}
> map /resource.json \
> http://resource_host/mapped/resource.json
> {noformat}
> parent.config
> {noformat}
> dest_domain=resource_host method=get parent="parent_host.domain.com:80"
> round_robin=consistent_hash go_direct=false
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4511) ATS crashes when no_dns_just_forward is configured without parent proxies
[ https://issues.apache.org/jira/browse/TS-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-4511: Fix Version/s: 7.0.0 > ATS crashes when no_dns_just_forward is configured without parent proxies > - > > Key: TS-4511 > URL: https://issues.apache.org/jira/browse/TS-4511 > Project: Traffic Server > Issue Type: Bug > Components: DNS, Parent Proxy >Reporter: Uri Shachar >Assignee: Uri Shachar > Fix For: 7.0.0 > > > When ATS is configured with: > CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1 > (and parent routing is enabled) > and a request comes in that does not have a parent defined for it in > parent.config ATS will abort with the following backtrace: > FATAL: HttpTransact.cc:7608: failed assertion `s->parent_result.result == > PARENT_FAIL` > ./bin/traffic_server(_ZN12HttpTransact18handle_parent_diedEPNS_5StateE+0x38)[0x6208fe] > ./bin/traffic_server(_ZN12HttpTransact23HandleCacheOpenReadMissEPNS_5StateE+0x686)[0x60e868] > ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x71)[0x5f118d] > ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74] > ./bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x40)[0x5f876a] > ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x75)[0x5f1347] > ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca] > ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xb21)[0x5f1df3] > ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca] > ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74] > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4511) ATS crashes when no_dns_just_forward is configured without parent proxies
[ https://issues.apache.org/jira/browse/TS-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318600#comment-15318600 ] Uri Shachar commented on TS-4511: - Because I'm not sure they're duplicates and I wanted to let the TS-3676 reporter reopen that one if it still happens. Not sure what you mean wrt HostDB -- This reproduces 100% of the time > ATS crashes when no_dns_just_forward is configured without parent proxies > - > > Key: TS-4511 > URL: https://issues.apache.org/jira/browse/TS-4511 > Project: Traffic Server > Issue Type: Bug > Components: DNS, Parent Proxy >Reporter: Uri Shachar >Assignee: Uri Shachar > Fix For: 7.0.0 > > > When ATS is configured with: > CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1 > (and parent routing is enabled) > and a request comes in that does not have a parent defined for it in > parent.config ATS will abort with the following backtrace: > FATAL: HttpTransact.cc:7608: failed assertion `s->parent_result.result == > PARENT_FAIL` > ./bin/traffic_server(_ZN12HttpTransact18handle_parent_diedEPNS_5StateE+0x38)[0x6208fe] > ./bin/traffic_server(_ZN12HttpTransact23HandleCacheOpenReadMissEPNS_5StateE+0x686)[0x60e868] > ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x71)[0x5f118d] > ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74] > ./bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x40)[0x5f876a] > ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x75)[0x5f1347] > ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca] > ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xb21)[0x5f1df3] > ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca] > ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74] > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (TS-4511) ATS crashes when no_dns_just_forward is configured without parent proxies
[
https://issues.apache.org/jira/browse/TS-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TS-4511 started by Uri Shachar.
---
> ATS crashes when no_dns_just_forward is configured without parent proxies
> -
>
> Key: TS-4511
> URL: https://issues.apache.org/jira/browse/TS-4511
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS, Parent Proxy
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>
> When ATS is configured with:
> {{CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1}}
> (and parent routing is enabled)
> and a request comes in that does not have a parent defined for it in
> parent.config ATS will abort with the following backtrace:
> {code}
> FATAL: HttpTransact.cc:7608: failed assertion `s->parent_result.result ==
> PARENT_FAIL`
> ./bin/traffic_server(_ZN12HttpTransact18handle_parent_diedEPNS_5StateE+0x38)[0x6208fe]
> ./bin/traffic_server(_ZN12HttpTransact23HandleCacheOpenReadMissEPNS_5StateE+0x686)[0x60e868]
> ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x71)[0x5f118d]
> ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74]
> ./bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x40)[0x5f876a]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x75)[0x5f1347]
> ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xb21)[0x5f1df3]
> ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca]
> ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74]
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4511) ATS crashes when no_dns_just_forward is configured without parent proxies
[
https://issues.apache.org/jira/browse/TS-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uri Shachar resolved TS-4511.
-
Resolution: Fixed
Fixed by PR# 698
> ATS crashes when no_dns_just_forward is configured without parent proxies
> -
>
> Key: TS-4511
> URL: https://issues.apache.org/jira/browse/TS-4511
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS, Parent Proxy
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>
> When ATS is configured with:
> {{CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1}}
> (and parent routing is enabled)
> and a request comes in that does not have a parent defined for it in
> parent.config ATS will abort with the following backtrace:
> {code}
> FATAL: HttpTransact.cc:7608: failed assertion `s->parent_result.result ==
> PARENT_FAIL`
> ./bin/traffic_server(_ZN12HttpTransact18handle_parent_diedEPNS_5StateE+0x38)[0x6208fe]
> ./bin/traffic_server(_ZN12HttpTransact23HandleCacheOpenReadMissEPNS_5StateE+0x686)[0x60e868]
> ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x71)[0x5f118d]
> ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74]
> ./bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x40)[0x5f876a]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x75)[0x5f1347]
> ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xb21)[0x5f1df3]
> ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca]
> ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74]
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4514) Transaction hangs when no_dns_just_forward is configured but parent proxy is unresolvable
Uri Shachar created TS-4514: --- Summary: Transaction hangs when no_dns_just_forward is configured but parent proxy is unresolvable Key: TS-4514 URL: https://issues.apache.org/jira/browse/TS-4514 Project: Traffic Server Issue Type: Bug Components: DNS, Parent Proxy Reporter: Uri Shachar When ATS is configured with: CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1 And a transaction comes in that has an unresolvable parent in parents.config ATS will keep retrying to resolve the same parent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (TS-4514) Transaction hangs when no_dns_just_forward is configured but parent proxy is unresolvable
[ https://issues.apache.org/jira/browse/TS-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-4514 started by Uri Shachar. --- > Transaction hangs when no_dns_just_forward is configured but parent proxy is > unresolvable > - > > Key: TS-4514 > URL: https://issues.apache.org/jira/browse/TS-4514 > Project: Traffic Server > Issue Type: Bug > Components: DNS, Parent Proxy >Reporter: Uri Shachar >Assignee: Uri Shachar > Fix For: 7.0.0 > > > When ATS is configured with: > > CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1 > > And a transaction comes in that has an unresolvable parent in parents.config > ATS will keep retrying to resolve the same parent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4514) Transaction hangs when no_dns_just_forward is configured but parent proxy is unresolvable
[ https://issues.apache.org/jira/browse/TS-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar reassigned TS-4514: --- Assignee: Uri Shachar > Transaction hangs when no_dns_just_forward is configured but parent proxy is > unresolvable > - > > Key: TS-4514 > URL: https://issues.apache.org/jira/browse/TS-4514 > Project: Traffic Server > Issue Type: Bug > Components: DNS, Parent Proxy >Reporter: Uri Shachar >Assignee: Uri Shachar > Fix For: 7.0.0 > > > When ATS is configured with: > > CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1 > > And a transaction comes in that has an unresolvable parent in parents.config > ATS will keep retrying to resolve the same parent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4514) Transaction hangs when no_dns_just_forward is configured but parent proxy is unresolvable
[ https://issues.apache.org/jira/browse/TS-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-4514: Fix Version/s: 7.0.0 > Transaction hangs when no_dns_just_forward is configured but parent proxy is > unresolvable > - > > Key: TS-4514 > URL: https://issues.apache.org/jira/browse/TS-4514 > Project: Traffic Server > Issue Type: Bug > Components: DNS, Parent Proxy >Reporter: Uri Shachar >Assignee: Uri Shachar > Fix For: 7.0.0 > > > When ATS is configured with: > > CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1 > > And a transaction comes in that has an unresolvable parent in parents.config > ATS will keep retrying to resolve the same parent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4514) Transaction hangs when no_dns_just_forward is configured but parent proxy is unresolvable
[
https://issues.apache.org/jira/browse/TS-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uri Shachar updated TS-4514:
Description:
When ATS is configured with:
{code}
CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
{code}
And a transaction comes in that has an unresolvable parent in parents.config
ATS will keep retrying to resolve the same parent.
was:
When ATS is configured with:
CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
And a transaction comes in that has an unresolvable parent in parents.config
ATS will keep retrying to resolve the same parent.
> Transaction hangs when no_dns_just_forward is configured but parent proxy is
> unresolvable
> -
>
> Key: TS-4514
> URL: https://issues.apache.org/jira/browse/TS-4514
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS, Parent Proxy
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>
> When ATS is configured with:
> {code}
> CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
> {code}
> And a transaction comes in that has an unresolvable parent in parents.config
> ATS will keep retrying to resolve the same parent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4404) proxy.config.http.no_dns_just_forward_to_parent is loaded in two places
[ https://issues.apache.org/jira/browse/TS-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar reassigned TS-4404: --- Assignee: Uri Shachar (was: John Rushford) > proxy.config.http.no_dns_just_forward_to_parent is loaded in two places > --- > > Key: TS-4404 > URL: https://issues.apache.org/jira/browse/TS-4404 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Leif Hedstrom >Assignee: Uri Shachar > Fix For: 7.0.0 > > > While looking at some code, I noticed that we load the config > proxy.config.http.no_dns_just_forward_to_parent both in HttpConfig.cc (for > the HttpSM) and in the parent code. > This is "fine", except it means there's no way now to make this configuration > overridable. If at all possible, can we only load this config in > HttpConfig.cc? If that's not doable, please just close this Jira as invalid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4514) Transaction hangs when no_dns_just_forward is configured but parent proxy is unresolvable
[
https://issues.apache.org/jira/browse/TS-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15321419#comment-15321419
]
Uri Shachar commented on TS-4514:
-
Fix for this is quite simple - remove the no_dns treatment in the parent
selection code and mark the parent as down on resolving failure so we try
another if possible.
This also resolves TS-4404 on the way
> Transaction hangs when no_dns_just_forward is configured but parent proxy is
> unresolvable
> -
>
> Key: TS-4514
> URL: https://issues.apache.org/jira/browse/TS-4514
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS, Parent Proxy
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>
> When ATS is configured with:
> {code}
> CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
> {code}
> And a transaction comes in that has an unresolvable parent in parents.config
> ATS will keep retrying to resolve the same parent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4511) ATS crashes when no_dns_just_forward is configured without parent proxies
[
https://issues.apache.org/jira/browse/TS-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15321428#comment-15321428
]
Uri Shachar commented on TS-4511:
-
Sure thing -- We seem to keep breaking the no_dns flag :-/
> ATS crashes when no_dns_just_forward is configured without parent proxies
> -
>
> Key: TS-4511
> URL: https://issues.apache.org/jira/browse/TS-4511
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS, Parent Proxy
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>
> When ATS is configured with:
> {{CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1}}
> (and parent routing is enabled)
> and a request comes in that does not have a parent defined for it in
> parent.config ATS will abort with the following backtrace:
> {code}
> FATAL: HttpTransact.cc:7608: failed assertion `s->parent_result.result ==
> PARENT_FAIL`
> ./bin/traffic_server(_ZN12HttpTransact18handle_parent_diedEPNS_5StateE+0x38)[0x6208fe]
> ./bin/traffic_server(_ZN12HttpTransact23HandleCacheOpenReadMissEPNS_5StateE+0x686)[0x60e868]
> ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x71)[0x5f118d]
> ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74]
> ./bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x40)[0x5f876a]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x75)[0x5f1347]
> ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca]
> ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xb21)[0x5f1df3]
> ./bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x5f12ca]
> ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x102)[0x5dbd74]
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4514) Transaction hangs when no_dns_just_forward is configured but parent proxy is unresolvable
[
https://issues.apache.org/jira/browse/TS-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uri Shachar resolved TS-4514.
-
Resolution: Fixed
> Transaction hangs when no_dns_just_forward is configured but parent proxy is
> unresolvable
> -
>
> Key: TS-4514
> URL: https://issues.apache.org/jira/browse/TS-4514
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS, Parent Proxy
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 7.0.0
>
>
> When ATS is configured with:
> {code}
> CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
> {code}
> And a transaction comes in that has an unresolvable parent in parents.config
> ATS will keep retrying to resolve the same parent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4404) proxy.config.http.no_dns_just_forward_to_parent is loaded in two places
[ https://issues.apache.org/jira/browse/TS-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar resolved TS-4404. - Resolution: Fixed > proxy.config.http.no_dns_just_forward_to_parent is loaded in two places > --- > > Key: TS-4404 > URL: https://issues.apache.org/jira/browse/TS-4404 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Leif Hedstrom >Assignee: Uri Shachar > Fix For: 7.0.0 > > > While looking at some code, I noticed that we load the config > proxy.config.http.no_dns_just_forward_to_parent both in HttpConfig.cc (for > the HttpSM) and in the parent code. > This is "fine", except it means there's no way now to make this configuration > overridable. If at all possible, can we only load this config in > HttpConfig.cc? If that's not doable, please just close this Jira as invalid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4404) proxy.config.http.no_dns_just_forward_to_parent is loaded in two places
[ https://issues.apache.org/jira/browse/TS-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15322066#comment-15322066 ] Uri Shachar commented on TS-4404: - This was resolved as part of TS-4515 -- the fix removed the no_dns awareness in the parent code. > proxy.config.http.no_dns_just_forward_to_parent is loaded in two places > --- > > Key: TS-4404 > URL: https://issues.apache.org/jira/browse/TS-4404 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Leif Hedstrom >Assignee: Uri Shachar > Fix For: 7.0.0 > > > While looking at some code, I noticed that we load the config > proxy.config.http.no_dns_just_forward_to_parent both in HttpConfig.cc (for > the HttpSM) and in the parent code. > This is "fine", except it means there's no way now to make this configuration > overridable. If at all possible, can we only load this config in > HttpConfig.cc? If that's not doable, please just close this Jira as invalid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (TS-4404) proxy.config.http.no_dns_just_forward_to_parent is loaded in two places
[ https://issues.apache.org/jira/browse/TS-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TS-4404 started by Uri Shachar. --- > proxy.config.http.no_dns_just_forward_to_parent is loaded in two places > --- > > Key: TS-4404 > URL: https://issues.apache.org/jira/browse/TS-4404 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: Leif Hedstrom >Assignee: Uri Shachar > Fix For: 7.0.0 > > > While looking at some code, I noticed that we load the config > proxy.config.http.no_dns_just_forward_to_parent both in HttpConfig.cc (for > the HttpSM) and in the parent code. > This is "fine", except it means there's no way now to make this configuration > overridable. If at all possible, can we only load this config in > HttpConfig.cc? If that's not doable, please just close this Jira as invalid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4523) Add the ability to pause/resume data consumption in the cpp api.
[ https://issues.apache.org/jira/browse/TS-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar reassigned TS-4523: --- Assignee: Uri Shachar > Add the ability to pause/resume data consumption in the cpp api. > > > Key: TS-4523 > URL: https://issues.apache.org/jira/browse/TS-4523 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: David Ben Zakai >Assignee: Uri Shachar > > It would be nice to be able to pause/resume the data consumption in the > Transformation Plugin. > Use case: > Manipulating the data in chunks (without reading all of it - waste of memory) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4523) Add the ability to pause/resume data consumption in the cpp api.
[ https://issues.apache.org/jira/browse/TS-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar reassigned TS-4523: --- Assignee: Uri Shachar > Add the ability to pause/resume data consumption in the cpp api. > > > Key: TS-4523 > URL: https://issues.apache.org/jira/browse/TS-4523 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: David Ben Zakai >Assignee: Uri Shachar > > It would be nice to be able to pause/resume the data consumption in the > Transformation Plugin. > Use case: > Manipulating the data in chunks (without reading all of it - waste of memory) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4523) Add the ability to pause/resume data consumption in the cpp api.
[ https://issues.apache.org/jira/browse/TS-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-4523: Assignee: (was: Uri Shachar) > Add the ability to pause/resume data consumption in the cpp api. > > > Key: TS-4523 > URL: https://issues.apache.org/jira/browse/TS-4523 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: David Ben Zakai > > It would be nice to be able to pause/resume the data consumption in the > Transformation Plugin. > Use case: > Manipulating the data in chunks (without reading all of it - waste of memory) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4523) Add the ability to pause/resume data consumption in the CPP API
[ https://issues.apache.org/jira/browse/TS-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-4523: Fix Version/s: 7.0.0 > Add the ability to pause/resume data consumption in the CPP API > --- > > Key: TS-4523 > URL: https://issues.apache.org/jira/browse/TS-4523 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: David Ben Zakai >Assignee: Uri Shachar > Fix For: 7.0.0 > > > It would be nice to be able to pause/resume the data consumption in the > Transformation Plugin. > Use case: > Manipulating the data in chunks (without reading all of it - waste of memory) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4523) Add the ability to pause/resume data consumption in the CPP API
[ https://issues.apache.org/jira/browse/TS-4523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-4523: Summary: Add the ability to pause/resume data consumption in the CPP API (was: Add the ability to pause/resume data consumption in the cpp api.) > Add the ability to pause/resume data consumption in the CPP API > --- > > Key: TS-4523 > URL: https://issues.apache.org/jira/browse/TS-4523 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: David Ben Zakai >Assignee: Uri Shachar > Fix For: 7.0.0 > > > It would be nice to be able to pause/resume the data consumption in the > Transformation Plugin. > Use case: > Manipulating the data in chunks (without reading all of it - waste of memory) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-1232) Support unknown methods in HTTP requests
Uri Shachar created TS-1232: --- Summary: Support unknown methods in HTTP requests Key: TS-1232 URL: https://issues.apache.org/jira/browse/TS-1232 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.3 Reporter: Uri Shachar When acting as a transparent proxy, we may intercept WebDAV and other HTTP based protocols. Currently, the response will be "405 Method Not Allowed" even though ATS can deal with the request as long as the rest of it is well-formed. Adding this functionality requires only minor changes and it could be configured on/off (proxy.config.http.accept_unknown_methods) Interested? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1331) Wrong regex for ip in records config
[ https://issues.apache.org/jira/browse/TS-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405959#comment-13405959 ] Uri Shachar commented on TS-1331: - The problem is with the regexp validation of the range regexp - need to add a couple more slashes... > Wrong regex for ip in records config > - > > Key: TS-1331 > URL: https://issues.apache.org/jira/browse/TS-1331 > Project: Traffic Server > Issue Type: Bug > Components: Management >Reporter: Yakov Kopel > Fix For: 3.3.0 > > Attachments: TS.diff > > > the regex check for ip that is done in recordIPCheck func in the > WebMgmtUtils.cc failed on valid ip, when trying to update by the traffic_line > api: > traffic_line -s proxy.config.cluster.mc_group_addr -v 224.0.1.37 > the problem is with the validation of the range string. > patch is attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1412) Traffic shell always suggests a hard restart on configuration change
Uri Shachar created TS-1412: --- Summary: Traffic shell always suggests a hard restart on configuration change Key: TS-1412 URL: https://issues.apache.org/jira/browse/TS-1412 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 3.2.0 Environment: Trunk build on Kubuntu 12.04 64 bit Reporter: Uri Shachar Priority: Minor There's a typo in CoreAPI.cc that causes it to always return a TS_ACTION_UNDEFINED instead of the correct action for the altered configuration value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1412) Traffic shell always suggests a hard restart on configuration change
[ https://issues.apache.org/jira/browse/TS-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1412: Attachment: fix_action_value.patch Attach patch. > Traffic shell always suggests a hard restart on configuration change > > > Key: TS-1412 > URL: https://issues.apache.org/jira/browse/TS-1412 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Affects Versions: 3.2.0 > Environment: Trunk build on Kubuntu 12.04 64 bit >Reporter: Uri Shachar >Priority: Minor > Attachments: fix_action_value.patch > > > There's a typo in CoreAPI.cc that causes it to always return a > TS_ACTION_UNDEFINED instead of the correct action for the altered > configuration value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1505) traffic server crash
[
https://issues.apache.org/jira/browse/TS-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465038#comment-13465038
]
Uri Shachar commented on TS-1505:
-
Looks like you have a duplicate line (line 8) in your remap configuration. If
ATS is unable to load the config it calls _exit
> traffic server crash
>
>
> Key: TS-1505
> URL: https://issues.apache.org/jira/browse/TS-1505
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.4
> Environment: os: centos 6.2 x64
>Reporter: lingjie.zhou
>Priority: Critical
>
> I have 12's ats server has run 3 month is very well, but in the past week 2
> ats server have been crashd, crash reason log is:
> [Sep 26 21:32:49.846] Manager {139893959927776} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '10'
> [Sep 26 21:32:49.846] Manager {139893959927776} NOTE: [Alarms::signalAlarm]
> Server Process born
> [Sep 26 21:32:50.859] {47599477855840} STATUS: opened
> /usr/local/ats/var/log/trafficserver/diags.log
> [Sep 26 21:32:50.859] {47599477855840} NOTE: updated diags config
> [Sep 26 21:32:50.861] Server {47599477855840} NOTE: cache clustering disabled
> [Sep 26 21:32:50.879] Server {47599477855840} NOTE: cache clustering disabled
> [Sep 26 21:32:50.908] Server {47599477855840} NOTE: logging initialized[7],
> logging_mode = 3
> [Sep 26 21:32:50.909] Server {47599477855840} ERROR: Cannot insert duplicate!
> [Sep 26 21:32:50.909] Server {47599477855840} ERROR: Couldn't insert into
> trie!
> [Sep 26 21:32:50.909] Server {47599477855840} WARNING: Could not insert new
> mapping
> [Sep 26 21:32:50.909] Server {47599477855840} WARNING: Could not add rule at
> line #8; Aborting!
> [Sep 26 21:32:50.909] Server {47599477855840} WARNING: [ReverseProxy] Unable
> to add mapping rule to lookup table at line 8
> [Sep 26 21:32:50.909] Server {47599477855840} WARNING: something failed
> during BuildTable() -- check your remap plugins!
> [Sep 26 21:32:50.909] Server {47599477855840} WARNING: Can not load the remap
> table, exiting out!
> [Sep 26 21:32:50.916] Manager {139893959927776} ERROR: [Alarms::signalAlarm]
> Server Process was reset
> [Sep 26 21:32:50.916] Manager {139893959927776} ERROR: (last system error 2:
> No such file or directory)
> [TrafficManager] ==> Cleaning up and reissuing signal #15
> [Sep 26 21:32:51.713] Manager {139893959927776} ERROR: [TrafficManager] ==>
> Cleaning up and reissuing signal #15
> [Sep 26 21:32:51.713] Manager {139893959927776} ERROR: (last system error 2:
> No such file or directory)
> [TrafficManager] ==> signal #15
> [Sep 26 21:32:51.713] Manager {139893959927776} ERROR: [TrafficManager] ==>
> signal #15
> [Sep 26 21:32:51.713] Manager {139893959927776} ERROR: (last system error 2:
> No such file or directory)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1516) use_client_addr breaks parent proxy configuration
Uri Shachar created TS-1516: --- Summary: use_client_addr breaks parent proxy configuration Key: TS-1516 URL: https://issues.apache.org/jira/browse/TS-1516 Project: Traffic Server Issue Type: Bug Components: Core, DNS Affects Versions: 3.2.0 Environment: CentOS 6.3. TPROXY + full transparency Reporter: Uri Shachar When use_client_addr is configured and a plugin/configuration tells the ATS to send the transaction to a parent proxy it will try to connect to the client address. Parent proxy settings should override the client IP. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1516) use_client_addr breaks parent proxy configuration
[ https://issues.apache.org/jira/browse/TS-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1516: Attachment: use_client_addr.patch Simple patch to fix the problem. > use_client_addr breaks parent proxy configuration > - > > Key: TS-1516 > URL: https://issues.apache.org/jira/browse/TS-1516 > Project: Traffic Server > Issue Type: Bug > Components: Core, DNS >Affects Versions: 3.2.0 > Environment: CentOS 6.3. TPROXY + full transparency >Reporter: Uri Shachar > Attachments: use_client_addr.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > When use_client_addr is configured and a plugin/configuration tells the ATS > to send the transaction to a parent proxy it will try to connect to the > client address. > Parent proxy settings should override the client IP. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1558) use_client_addr breaks control over upstream HTTP protocol version
Uri Shachar created TS-1558: --- Summary: use_client_addr breaks control over upstream HTTP protocol version Key: TS-1558 URL: https://issues.apache.org/jira/browse/TS-1558 Project: Traffic Server Issue Type: Bug Components: Core, HTTP Affects Versions: 3.3.3, 3.2.3 Environment: Trunc running on CentOS 6.3, 64bit Reporter: Uri Shachar Priority: Critical If use_client_addr is turned on, we skip the hostdb lookup so we never know if the upstream has previously responded with an HTTP/1.1 response. This means that unless proxy.config.http.send_http11_requests is set to 1 we will always send HTTP/1.0 requests to upstream. I'll attach a patch that sets 'upstream server version = client request version' (which seems correct for a transparent interception scenario) -- an alternative implementation might be to modify the hostdb lookup flow to skip the actual DNS resolving and treat the client provided address as a DNS provided one -- Comments? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1558) use_client_addr breaks control over upstream HTTP protocol version
[ https://issues.apache.org/jira/browse/TS-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1558: Attachment: use_client_version.patch > use_client_addr breaks control over upstream HTTP protocol version > -- > > Key: TS-1558 > URL: https://issues.apache.org/jira/browse/TS-1558 > Project: Traffic Server > Issue Type: Bug > Components: Core, HTTP >Affects Versions: 3.3.3, 3.2.3 > Environment: Trunc running on CentOS 6.3, 64bit >Reporter: Uri Shachar >Priority: Critical > Attachments: use_client_version.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > If use_client_addr is turned on, we skip the hostdb lookup so we never know > if the upstream has previously responded with an HTTP/1.1 response. > This means that unless proxy.config.http.send_http11_requests is set to 1 we > will always send HTTP/1.0 requests to upstream. > I'll attach a patch that sets 'upstream server version = client request > version' (which seems correct for a transparent interception scenario) -- an > alternative implementation might be to modify the hostdb lookup flow to skip > the actual DNS resolving and treat the client provided address as a DNS > provided one -- Comments? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1558) use_client_addr breaks control over upstream HTTP protocol version
[ https://issues.apache.org/jira/browse/TS-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1558: Attachment: comment_typos.patch Completely non-related and probably belongs in another jira -- but I've added a small patch to fix two comment typos in HttpTransact... (I know authorized can be spelt with an s -- but we don't do that anywhere else in the code) > use_client_addr breaks control over upstream HTTP protocol version > -- > > Key: TS-1558 > URL: https://issues.apache.org/jira/browse/TS-1558 > Project: Traffic Server > Issue Type: Bug > Components: Core, HTTP >Affects Versions: 3.3.3, 3.2.3 > Environment: Trunc running on CentOS 6.3, 64bit >Reporter: Uri Shachar >Priority: Critical > Attachments: comment_typos.patch, use_client_version.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > If use_client_addr is turned on, we skip the hostdb lookup so we never know > if the upstream has previously responded with an HTTP/1.1 response. > This means that unless proxy.config.http.send_http11_requests is set to 1 we > will always send HTTP/1.0 requests to upstream. > I'll attach a patch that sets 'upstream server version = client request > version' (which seems correct for a transparent interception scenario) -- an > alternative implementation might be to modify the hostdb lookup flow to skip > the actual DNS resolving and treat the client provided address as a DNS > provided one -- Comments? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1558) use_client_addr breaks control over upstream HTTP protocol version
[ https://issues.apache.org/jira/browse/TS-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1558: Environment: Trunk running on CentOS 6.3, 64bit (was: Trunc running on CentOS 6.3, 64bit) > use_client_addr breaks control over upstream HTTP protocol version > -- > > Key: TS-1558 > URL: https://issues.apache.org/jira/browse/TS-1558 > Project: Traffic Server > Issue Type: Bug > Components: Core, HTTP >Affects Versions: 3.3.3, 3.2.3 > Environment: Trunk running on CentOS 6.3, 64bit >Reporter: Uri Shachar >Priority: Critical > Attachments: comment_typos.patch, use_client_version.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > If use_client_addr is turned on, we skip the hostdb lookup so we never know > if the upstream has previously responded with an HTTP/1.1 response. > This means that unless proxy.config.http.send_http11_requests is set to 1 we > will always send HTTP/1.0 requests to upstream. > I'll attach a patch that sets 'upstream server version = client request > version' (which seems correct for a transparent interception scenario) -- an > alternative implementation might be to modify the hostdb lookup flow to skip > the actual DNS resolving and treat the client provided address as a DNS > provided one -- Comments? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1558) use_client_addr breaks control over upstream HTTP protocol version
[ https://issues.apache.org/jira/browse/TS-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489345#comment-13489345 ] Uri Shachar commented on TS-1558: - If we are configured to always/never send HTTP/1.1 requests, that configuration will still take precedence. Since we do not do a hostdb lookup, the last two options: # 2 - if the server has returned http1.1 before # 3 - if the client request is 1.1 & the server has returned 1.1 before are problematic as we will never know if the server has previously returned a 1.1 response. All the patch does is set the 'previously seen server version' to be equal to the client request version -- so if we are running with config option 2/3 set we will always send a request version that equals the client request version (which seems the best thing we can do in this transparent use case). I'll add a patch that flips the check order so we mark the server as HTTP/1.1 if the client request version is unfamiliar + add a comment to records.config. > use_client_addr breaks control over upstream HTTP protocol version > -- > > Key: TS-1558 > URL: https://issues.apache.org/jira/browse/TS-1558 > Project: Traffic Server > Issue Type: Bug > Components: Core, HTTP >Affects Versions: 3.3.3, 3.2.3 > Environment: Trunk running on CentOS 6.3, 64bit >Reporter: Uri Shachar >Priority: Critical > Attachments: comment_typos.patch, use_client_version.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > If use_client_addr is turned on, we skip the hostdb lookup so we never know > if the upstream has previously responded with an HTTP/1.1 response. > This means that unless proxy.config.http.send_http11_requests is set to 1 we > will always send HTTP/1.0 requests to upstream. > I'll attach a patch that sets 'upstream server version = client request > version' (which seems correct for a transparent interception scenario) -- an > alternative implementation might be to modify the hostdb lookup flow to skip > the actual DNS resolving and treat the client provided address as a DNS > provided one -- Comments? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1558) use_client_addr breaks control over upstream HTTP protocol version
[ https://issues.apache.org/jira/browse/TS-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1558: Attachment: (was: use_client_version.patch) > use_client_addr breaks control over upstream HTTP protocol version > -- > > Key: TS-1558 > URL: https://issues.apache.org/jira/browse/TS-1558 > Project: Traffic Server > Issue Type: Bug > Components: Core, HTTP >Affects Versions: 3.3.3, 3.2.3 > Environment: Trunk running on CentOS 6.3, 64bit >Reporter: Uri Shachar >Priority: Critical > Attachments: comment_typos.patch, use_client_version.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > If use_client_addr is turned on, we skip the hostdb lookup so we never know > if the upstream has previously responded with an HTTP/1.1 response. > This means that unless proxy.config.http.send_http11_requests is set to 1 we > will always send HTTP/1.0 requests to upstream. > I'll attach a patch that sets 'upstream server version = client request > version' (which seems correct for a transparent interception scenario) -- an > alternative implementation might be to modify the hostdb lookup flow to skip > the actual DNS resolving and treat the client provided address as a DNS > provided one -- Comments? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1558) use_client_addr breaks control over upstream HTTP protocol version
[ https://issues.apache.org/jira/browse/TS-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1558: Attachment: use_client_version.patch New patch - Use HTTP/1.1 if the client request version isn't 0.9/1.0 + comment in records.config > use_client_addr breaks control over upstream HTTP protocol version > -- > > Key: TS-1558 > URL: https://issues.apache.org/jira/browse/TS-1558 > Project: Traffic Server > Issue Type: Bug > Components: Core, HTTP >Affects Versions: 3.3.3, 3.2.3 > Environment: Trunk running on CentOS 6.3, 64bit >Reporter: Uri Shachar >Priority: Critical > Attachments: comment_typos.patch, use_client_version.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > If use_client_addr is turned on, we skip the hostdb lookup so we never know > if the upstream has previously responded with an HTTP/1.1 response. > This means that unless proxy.config.http.send_http11_requests is set to 1 we > will always send HTTP/1.0 requests to upstream. > I'll attach a patch that sets 'upstream server version = client request > version' (which seems correct for a transparent interception scenario) -- an > alternative implementation might be to modify the hostdb lookup flow to skip > the actual DNS resolving and treat the client provided address as a DNS > provided one -- Comments? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1559) Server side termination not handled properly when a PluginVC/Protocol Plugin is used
[ https://issues.apache.org/jira/browse/TS-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491388#comment-13491388 ] Uri Shachar commented on TS-1559: - When this patch is integrated we should give a heads-up to protocol plugin developers/users -- it causes a slight behavior change -- In some cases we can now get a TS_EVENT_VCONN_WRITE_READY on the client write VIO after the server read vio has been freed (so if you'll segfault if you try to reenable). Since the plugin will always get an EOS event beforehand it's pretty easy to adjust for this. > Server side termination not handled properly when a PluginVC/Protocol Plugin > is used > - > > Key: TS-1559 > URL: https://issues.apache.org/jira/browse/TS-1559 > Project: Traffic Server > Issue Type: Bug > Components: HTTP, Plugins >Affects Versions: 3.3.1 >Reporter: Yossi Gottlieb > Attachments: pluginvc_tunnel.diff > > > Using a Protocol Plugin along with a PluginVC (HttpConnect) and HTTP CONNECT > command to create tunnel. When the server drops the connection, the protocol > plugin will not be notified until the connection times out. > HttpSM ends up calling PluginVC::do_io_shutdown() which sets the appropriate > flags but takes no action. I suspect this would affect real socket VCs as > well, but in that case the shutdown() on the socket write side would cause > the client to react and close its own side as well. > The proposed fix solves my specific problem but may not address all related > issues (with PluginVCs or other types of VCs as well). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1423) Blind tunneling of garbage/invalid requests when using transparent interception
[ https://issues.apache.org/jira/browse/TS-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495144#comment-13495144 ] Uri Shachar commented on TS-1423: - We've got a patch for this that allows the user to configure tunneling if the '''first''' request fails parsing. Yossi will upload it after a bit of QA. > Blind tunneling of garbage/invalid requests when using transparent > interception > --- > > Key: TS-1423 > URL: https://issues.apache.org/jira/browse/TS-1423 > Project: Traffic Server > Issue Type: New Feature >Affects Versions: 3.2.0 > Environment: 3.2 with TProxy inteception and > proxy.config.http.use_client_target_addr == 1 >Reporter: B Wyatt >Assignee: Alan M. Carroll > Fix For: 3.3.2 > > > Presently, when ATS encounters a request that it cannot parse or that is > malformed in any way, it sends an error response to the client. > When using transparent interception and > proxy.config.http.use_client_target_addr ATS should have enough information > to blindly tunnel the original "transmission" to the desired endpoint and > maintain the service regardless of HTTP/1.x compliance and moreover if it is > non-HTTP communication over port 80. > Bonus would be support for supporting alien protocols where the server speaks > first however, ambiguity over a slow incoming request and an expectation that > the server speaks first can make that difficult. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TS-1423) Blind tunneling of garbage/invalid requests when using transparent interception
[ https://issues.apache.org/jira/browse/TS-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495144#comment-13495144 ] Uri Shachar edited comment on TS-1423 at 11/12/12 7:54 AM: --- We've got a patch for this that allows the user to configure tunneling if the *first* request fails parsing. Yossi will upload it after a bit of QA. was (Author: ushachar): We've got a patch for this that allows the user to configure tunneling if the '''first''' request fails parsing. Yossi will upload it after a bit of QA. > Blind tunneling of garbage/invalid requests when using transparent > interception > --- > > Key: TS-1423 > URL: https://issues.apache.org/jira/browse/TS-1423 > Project: Traffic Server > Issue Type: New Feature >Affects Versions: 3.2.0 > Environment: 3.2 with TProxy inteception and > proxy.config.http.use_client_target_addr == 1 >Reporter: B Wyatt >Assignee: Alan M. Carroll > Fix For: 3.3.2 > > > Presently, when ATS encounters a request that it cannot parse or that is > malformed in any way, it sends an error response to the client. > When using transparent interception and > proxy.config.http.use_client_target_addr ATS should have enough information > to blindly tunnel the original "transmission" to the desired endpoint and > maintain the service regardless of HTTP/1.x compliance and moreover if it is > non-HTTP communication over port 80. > Bonus would be support for supporting alien protocols where the server speaks > first however, ambiguity over a slow incoming request and an expectation that > the server speaks first can make that difficult. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1572) Plugin response status change can trigger ATS assertion later on
Uri Shachar created TS-1572: --- Summary: Plugin response status change can trigger ATS assertion later on Key: TS-1572 URL: https://issues.apache.org/jira/browse/TS-1572 Project: Traffic Server Issue Type: Bug Components: HTTP, Plugins, Stats Affects Versions: 3.3.0 Environment: Trunk ATS, fully transparent Reporter: Uri Shachar Priority: Trivial After a transaction comes in and the ATS detects a multi hop cycle, my plugin used to set a 200 status code on the response (obviously buggy, but still) This would trigger an assertion in the HttpTransact::client_result_stat function when the http debug tag is turned on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1572) Plugin response status change can trigger ATS assertion later on
[ https://issues.apache.org/jira/browse/TS-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1572: Attachment: stop_cycle_asserts.patch simple patch -- Issue a debug and don't assert > Plugin response status change can trigger ATS assertion later on > > > Key: TS-1572 > URL: https://issues.apache.org/jira/browse/TS-1572 > Project: Traffic Server > Issue Type: Bug > Components: HTTP, Plugins, Stats >Affects Versions: 3.3.0 > Environment: Trunk ATS, fully transparent >Reporter: Uri Shachar >Priority: Trivial > Attachments: stop_cycle_asserts.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > After a transaction comes in and the ATS detects a multi hop cycle, my plugin > used to set a 200 status code on the response (obviously buggy, but still) > This would trigger an assertion in the HttpTransact::client_result_stat > function when the http debug tag is turned on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1423) Blind tunneling of garbage/invalid requests when using transparent interception
[ https://issues.apache.org/jira/browse/TS-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13528817#comment-13528817 ] Uri Shachar commented on TS-1423: - Alan - Any issues with this patch? The extra ntohs in HttpTransact should be removed in any case I'll submit another ticket just for that if needed. > Blind tunneling of garbage/invalid requests when using transparent > interception > --- > > Key: TS-1423 > URL: https://issues.apache.org/jira/browse/TS-1423 > Project: Traffic Server > Issue Type: New Feature >Affects Versions: 3.2.0 > Environment: 3.2 with TProxy inteception and > proxy.config.http.use_client_target_addr == 1 >Reporter: B Wyatt >Assignee: Alan M. Carroll > Fix For: 3.3.3 > > Attachments: transparent_passthrough.diff > > > Presently, when ATS encounters a request that it cannot parse or that is > malformed in any way, it sends an error response to the client. > When using transparent interception and > proxy.config.http.use_client_target_addr ATS should have enough information > to blindly tunnel the original "transmission" to the desired endpoint and > maintain the service regardless of HTTP/1.x compliance and moreover if it is > non-HTTP communication over port 80. > Bonus would be support for supporting alien protocols where the server speaks > first however, ambiguity over a slow incoming request and an expectation that > the server speaks first can make that difficult. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1423) Blind tunneling of garbage/invalid requests when using transparent interception
[ https://issues.apache.org/jira/browse/TS-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530015#comment-13530015 ] Uri Shachar commented on TS-1423: - I believe you're right in comment 1 -- we could just check if the ua_raw_buffer_reader isn't null. As to comment 2, since this is only for transparent setups the local proxy port is probably less important (since multiple dst ports may very well be tproxied to the same ATS port). Adding a config option similar to proxy.config.http.connect_ports (or altering the syntax of the proxy.config.http.transparent_passthrough to specify dst ports) seems more useful > Blind tunneling of garbage/invalid requests when using transparent > interception > --- > > Key: TS-1423 > URL: https://issues.apache.org/jira/browse/TS-1423 > Project: Traffic Server > Issue Type: New Feature >Affects Versions: 3.2.0 > Environment: 3.2 with TProxy inteception and > proxy.config.http.use_client_target_addr == 1 >Reporter: B Wyatt >Assignee: Alan M. Carroll > Fix For: 3.3.3 > > Attachments: transparent_passthrough.diff > > > Presently, when ATS encounters a request that it cannot parse or that is > malformed in any way, it sends an error response to the client. > When using transparent interception and > proxy.config.http.use_client_target_addr ATS should have enough information > to blindly tunnel the original "transmission" to the desired endpoint and > maintain the service regardless of HTTP/1.x compliance and moreover if it is > non-HTTP communication over port 80. > Bonus would be support for supporting alien protocols where the server speaks > first however, ambiguity over a slow incoming request and an expectation that > the server speaks first can make that difficult. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1423) Blind tunneling of garbage/invalid requests when using transparent interception
[ https://issues.apache.org/jira/browse/TS-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533306#comment-13533306 ] Uri Shachar commented on TS-1423: - @Alan - What would be the point in only bypassing on request line parsing failure? If the header parsing fails ATS won't be able to handle the request, and will return an error msg to the user > Blind tunneling of garbage/invalid requests when using transparent > interception > --- > > Key: TS-1423 > URL: https://issues.apache.org/jira/browse/TS-1423 > Project: Traffic Server > Issue Type: New Feature >Affects Versions: 3.2.0 > Environment: 3.2 with TProxy inteception and > proxy.config.http.use_client_target_addr == 1 >Reporter: B Wyatt >Assignee: Alan M. Carroll > Fix For: 3.3.3 > > Attachments: transparent_passthrough_as_port_option.diff, > transparent_passthrough.diff > > > Presently, when ATS encounters a request that it cannot parse or that is > malformed in any way, it sends an error response to the client. > When using transparent interception and > proxy.config.http.use_client_target_addr ATS should have enough information > to blindly tunnel the original "transmission" to the desired endpoint and > maintain the service regardless of HTTP/1.x compliance and moreover if it is > non-HTTP communication over port 80. > Bonus would be support for supporting alien protocols where the server speaks > first however, ambiguity over a slow incoming request and an expectation that > the server speaks first can make that difficult. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1627) Support GET requests with payload
Uri Shachar created TS-1627: --- Summary: Support GET requests with payload Key: TS-1627 URL: https://issues.apache.org/jira/browse/TS-1627 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Uri Shachar >From what I understand from RFC 2616, these requests should be legal. ATS >currently accepts these requests, but drops the body when passing them onward >to the upstream. Most discussion that I could find on the web say that this is legal -- although what the upstream can actually do with the payload isn't clear http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html http://tech.groups.yahoo.com/group/rest-discuss/message/9957 http://stackoverflow.com/questions/978061/http-get-with-request-body http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1627) Support GET requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1627: Affects Version/s: 3.3.0 > Support GET requests with payload > - > > Key: TS-1627 > URL: https://issues.apache.org/jira/browse/TS-1627 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: Uri Shachar > Attachments: get_with_payload.patch > > > From what I understand from RFC 2616, these requests should be legal. ATS > currently accepts these requests, but drops the body when passing them onward > to the upstream. > Most discussion that I could find on the web say that this is legal -- > although what the upstream can actually do with the payload isn't clear > http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html > http://tech.groups.yahoo.com/group/rest-discuss/message/9957 > http://stackoverflow.com/questions/978061/http-get-with-request-body > http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1627) Support GET requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1627: Attachment: get_with_payload.patch The proposed patch only fixes the problem for requests with a Content-Length header. GET requests with "Transfer-Encoding: chunked" will still be stripped of payload. Fixing this isn't very complicated, but will make the code uglier -- I don't think it's worth it > Support GET requests with payload > - > > Key: TS-1627 > URL: https://issues.apache.org/jira/browse/TS-1627 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Uri Shachar > Attachments: get_with_payload.patch > > > From what I understand from RFC 2616, these requests should be legal. ATS > currently accepts these requests, but drops the body when passing them onward > to the upstream. > Most discussion that I could find on the web say that this is legal -- > although what the upstream can actually do with the payload isn't clear > http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html > http://tech.groups.yahoo.com/group/rest-discuss/message/9957 > http://stackoverflow.com/questions/978061/http-get-with-request-body > http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TS-1627) Support GET requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533388#comment-13533388 ] Uri Shachar edited comment on TS-1627 at 12/16/12 1:22 PM: --- The proposed patch only fixes the problem for requests with a Content-Length header. GET requests with "Transfer-Encoding: chunked" will still be stripped of payload. Fixing this isn't very complicated, but will make the code uglier -- I don't think it's worth it Also -- The change to HttpTransact::check_request_validity isn't really necessary, but it removes a redundant check (I had a change there and then noticed it wasn't needed). was (Author: ushachar): The proposed patch only fixes the problem for requests with a Content-Length header. GET requests with "Transfer-Encoding: chunked" will still be stripped of payload. Fixing this isn't very complicated, but will make the code uglier -- I don't think it's worth it > Support GET requests with payload > - > > Key: TS-1627 > URL: https://issues.apache.org/jira/browse/TS-1627 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: Uri Shachar > Attachments: get_with_payload.patch > > > From what I understand from RFC 2616, these requests should be legal. ATS > currently accepts these requests, but drops the body when passing them onward > to the upstream. > Most discussion that I could find on the web say that this is legal -- > although what the upstream can actually do with the payload isn't clear > http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html > http://tech.groups.yahoo.com/group/rest-discuss/message/9957 > http://stackoverflow.com/questions/978061/http-get-with-request-body > http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-1232) Support unknown methods in HTTP requests
[ https://issues.apache.org/jira/browse/TS-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar resolved TS-1232. - Resolution: Duplicate Fix Version/s: (was: 3.3.1) 3.3.0 3.2.3 > Support unknown methods in HTTP requests > > > Key: TS-1232 > URL: https://issues.apache.org/jira/browse/TS-1232 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 3.1.3 >Reporter: Uri Shachar > Labels: http > Fix For: 3.2.3, 3.3.0 > > Original Estimate: 72h > Remaining Estimate: 72h > > When acting as a transparent proxy, we may intercept WebDAV and other HTTP > based protocols. > Currently, the response will be "405 Method Not Allowed" even though ATS can > deal with the request as long as the rest of it is well-formed. > Adding this functionality requires only minor changes and it could be > configured on/off (proxy.config.http.accept_unknown_methods) > Interested? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1232) Support unknown methods in HTTP requests
[ https://issues.apache.org/jira/browse/TS-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13536898#comment-13536898 ] Uri Shachar commented on TS-1232: - Completely forgot about this one -- It actually works in trunk and 3.2 branches... (all that was missing was a change to the ip_allow and that was done as part of TS-1407) > Support unknown methods in HTTP requests > > > Key: TS-1232 > URL: https://issues.apache.org/jira/browse/TS-1232 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 3.1.3 >Reporter: Uri Shachar > Labels: http > Fix For: 3.3.1 > > Original Estimate: 72h > Remaining Estimate: 72h > > When acting as a transparent proxy, we may intercept WebDAV and other HTTP > based protocols. > Currently, the response will be "405 Method Not Allowed" even though ATS can > deal with the request as long as the rest of it is well-formed. > Adding this functionality requires only minor changes and it could be > configured on/off (proxy.config.http.accept_unknown_methods) > Interested? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TS-1232) Support unknown methods in HTTP requests
[ https://issues.apache.org/jira/browse/TS-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar closed TS-1232. --- > Support unknown methods in HTTP requests > > > Key: TS-1232 > URL: https://issues.apache.org/jira/browse/TS-1232 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Affects Versions: 3.1.3 >Reporter: Uri Shachar > Labels: http > Fix For: 3.3.0, 3.2.3 > > Original Estimate: 72h > Remaining Estimate: 72h > > When acting as a transparent proxy, we may intercept WebDAV and other HTTP > based protocols. > Currently, the response will be "405 Method Not Allowed" even though ATS can > deal with the request as long as the rest of it is well-formed. > Adding this functionality requires only minor changes and it could be > configured on/off (proxy.config.http.accept_unknown_methods) > Interested? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1627) Support GET requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13537133#comment-13537133 ] Uri Shachar commented on TS-1627: - AFAICT - The only method that is explicitly prohibited from having a body is TRACE -- The code should actually be simpler if I simply switch it to filter based on that I'll take another look and see if I can generate a patch that's clean enough for both this and chunked encoding > Support GET requests with payload > - > > Key: TS-1627 > URL: https://issues.apache.org/jira/browse/TS-1627 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: Uri Shachar > Attachments: get_with_payload.patch > > > From what I understand from RFC 2616, these requests should be legal. ATS > currently accepts these requests, but drops the body when passing them onward > to the upstream. > Most discussion that I could find on the web say that this is legal -- > although what the upstream can actually do with the payload isn't clear > http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html > http://tech.groups.yahoo.com/group/rest-discuss/message/9957 > http://stackoverflow.com/questions/978061/http-get-with-request-body > http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1674) TSStatIntDecrement is broken
[ https://issues.apache.org/jira/browse/TS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13567418#comment-13567418 ] Uri Shachar commented on TS-1674: - This may cause problems with our patch for TS-1631 (supporting the ability to reset individual stats). I've been thinking that the 'correct' way to go here would be to unify all stats instead of maintaining a per thread copy -- thoughts? > TSStatIntDecrement is broken > > > Key: TS-1674 > URL: https://issues.apache.org/jira/browse/TS-1674 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.3.1 > > > ATS keeps a thread-local copy of the stat value and aggregates it > periodically and on demand when stats are being collected. However the > decrement function doesn't let a value go negative. So in a thread that has > not incremented this stat previously, the decrement call "fails". This > negative value check is logically flawed as it doesn't account for the > per-thread distribution of the stats. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1674) TSStatIntDecrement is broken
[ https://issues.apache.org/jira/browse/TS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13567713#comment-13567713 ] Uri Shachar commented on TS-1674: - As I see it, there's probably no need for locks (working directly with atomic variables) -- but there might be a perf impact to working with atomics all the time instead of only during the aggregation. > TSStatIntDecrement is broken > > > Key: TS-1674 > URL: https://issues.apache.org/jira/browse/TS-1674 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.3.1 > > > ATS keeps a thread-local copy of the stat value and aggregates it > periodically and on demand when stats are being collected. However the > decrement function doesn't let a value go negative. So in a thread that has > not incremented this stat previously, the decrement call "fails". This > negative value check is logically flawed as it doesn't account for the > per-thread distribution of the stats. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1627) Support GET requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1627: Attachment: requests_with_content.patch Uploaded new patch that properly handles requests that have content. TRACE isn't allowed to have payload POST/PUT are required to specific CL/Chunked > Support GET requests with payload > - > > Key: TS-1627 > URL: https://issues.apache.org/jira/browse/TS-1627 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: Uri Shachar > Attachments: get_with_payload.patch, requests_with_content.patch > > > From what I understand from RFC 2616, these requests should be legal. ATS > currently accepts these requests, but drops the body when passing them onward > to the upstream. > Most discussion that I could find on the web say that this is legal -- > although what the upstream can actually do with the payload isn't clear > http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html > http://tech.groups.yahoo.com/group/rest-discuss/message/9957 > http://stackoverflow.com/questions/978061/http-get-with-request-body > http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TS-1627) Support GET requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569800#comment-13569800 ] Uri Shachar edited comment on TS-1627 at 2/3/13 3:31 PM: - Uploaded new patch that properly handles requests that have content. TRACE isn't allowed to have payload POST/PUT must specify either Content-Length or Transfer-Encoding:Chunked was (Author: ushachar): Uploaded new patch that properly handles requests that have content. TRACE isn't allowed to have payload POST/PUT are required to specific CL/Chunked > Support GET requests with payload > - > > Key: TS-1627 > URL: https://issues.apache.org/jira/browse/TS-1627 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: Uri Shachar > Attachments: get_with_payload.patch, requests_with_content.patch > > > From what I understand from RFC 2616, these requests should be legal. ATS > currently accepts these requests, but drops the body when passing them onward > to the upstream. > Most discussion that I could find on the web say that this is legal -- > although what the upstream can actually do with the payload isn't clear > http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html > http://tech.groups.yahoo.com/group/rest-discuss/message/9957 > http://stackoverflow.com/questions/978061/http-get-with-request-body > http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1674) TSStatIntDecrement is broken
[ https://issues.apache.org/jira/browse/TS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570133#comment-13570133 ] Uri Shachar commented on TS-1674: - I did some quick benchmarks with a sample program -- At worse, it seems like using atomic long longs is ~6-7 times slower then regular long longs (This is obviously dependant on arch/compiler -- I used GCC over 64bit x86). My guess would be that the impact on ATS wouldn't be noticeable (since there will be some improvement from the code simplification). I'll try to cobble together a working patch and check it out > TSStatIntDecrement is broken > > > Key: TS-1674 > URL: https://issues.apache.org/jira/browse/TS-1674 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.3.1 > > > ATS keeps a thread-local copy of the stat value and aggregates it > periodically and on demand when stats are being collected. However the > decrement function doesn't let a value go negative. So in a thread that has > not incremented this stat previously, the decrement call "fails". This > negative value check is logically flawed as it doesn't account for the > per-thread distribution of the stats. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1626) remove WUTS proxy code
[ https://issues.apache.org/jira/browse/TS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572344#comment-13572344 ] Uri Shachar commented on TS-1626: - I've dug around code from ~2006 -- haven't been able to find any useful info on this (It does seem to be related to the log_spider_codes option). Maybe John Plevyak knows what it's all about? > remove WUTS proxy code > -- > > Key: TS-1626 > URL: https://issues.apache.org/jira/browse/TS-1626 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: James Peach > > There is a bunch of code doing something with "WUTS proxy status codes". What > is a WUTS and why do we care? If this is cruft, let's get rid of it! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1627) Support requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1627: Summary: Support requests with payload (was: Support GET requests with payload) > Support requests with payload > - > > Key: TS-1627 > URL: https://issues.apache.org/jira/browse/TS-1627 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: Uri Shachar > Attachments: get_with_payload.patch, requests_with_content.patch > > > From what I understand from RFC 2616, these requests should be legal. ATS > currently accepts these requests, but drops the body when passing them onward > to the upstream. > Most discussion that I could find on the web say that this is legal -- > although what the upstream can actually do with the payload isn't clear > http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html > http://tech.groups.yahoo.com/group/rest-discuss/message/9957 > http://stackoverflow.com/questions/978061/http-get-with-request-body > http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1708) Using tr-pass port option causes requests with large headers to hang
Uri Shachar created TS-1708: --- Summary: Using tr-pass port option causes requests with large headers to hang Key: TS-1708 URL: https://issues.apache.org/jira/browse/TS-1708 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Uri Shachar When tr-pass is enabled and a request comes in with total size of request headers > 4K it will hang in the parser (and never time out). In order to support tr-pass, we clone the ua_buffer_reader, but until the parser decides the request is valid/invalid, we do not consume data from the clone. Eventually, the underlying iobuffer fills up and the parser won't be called with the rest of the pending data. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1708) Using tr-pass port option causes requests with large headers to hang
[ https://issues.apache.org/jira/browse/TS-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1708: Attachment: transparent_passthrough_hang.diff This patch turns off the passthrough if the buffer is full and we still don't have a decision if the request is valid. If it proves to be invalid, a normal HTTP error will be returned (as if tr-pass wasn't enabled) I'm not sure if there isn't another bug being covered up here -- If I understand the IOBuffer implementation correctly, it should allow the writer to continue writing since the watermark is set to 0 > Using tr-pass port option causes requests with large headers to hang > > > Key: TS-1708 > URL: https://issues.apache.org/jira/browse/TS-1708 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Uri Shachar > Attachments: transparent_passthrough_hang.diff > > > When tr-pass is enabled and a request comes in with total size of request > headers > 4K it will hang in the parser (and never time out). > In order to support tr-pass, we clone the ua_buffer_reader, but until the > parser decides the request is valid/invalid, we do not consume data from the > clone. Eventually, the underlying iobuffer fills up and the parser won't be > called with the rest of the pending data. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1708) Using tr-pass port option causes requests with large headers to hang
[ https://issues.apache.org/jira/browse/TS-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1708: Description: When tr-pass is enabled and a request comes in on a new connection with total size of request headers > 4K it will hang in the parser (and never time out). In order to support tr-pass, we clone the ua_buffer_reader, but until the parser decides the request is valid/invalid, we do not consume data from the clone. Eventually, the underlying iobuffer fills up and the parser won't be called with the rest of the pending data. was: When tr-pass is enabled and a request comes in with total size of request headers > 4K it will hang in the parser (and never time out). In order to support tr-pass, we clone the ua_buffer_reader, but until the parser decides the request is valid/invalid, we do not consume data from the clone. Eventually, the underlying iobuffer fills up and the parser won't be called with the rest of the pending data. > Using tr-pass port option causes requests with large headers to hang > > > Key: TS-1708 > URL: https://issues.apache.org/jira/browse/TS-1708 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Uri Shachar > Attachments: transparent_passthrough_hang.diff > > > When tr-pass is enabled and a request comes in on a new connection with total > size of request headers > 4K it will hang in the parser (and never time out). > In order to support tr-pass, we clone the ua_buffer_reader, but until the > parser decides the request is valid/invalid, we do not consume data from the > clone. Eventually, the underlying iobuffer fills up and the parser won't be > called with the rest of the pending data. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1632) RecDecrRawStat does not seem to work as intended
[ https://issues.apache.org/jira/browse/TS-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13578571#comment-13578571 ] Uri Shachar commented on TS-1632: - Note that the first diff was already applied as a fix for TS-1674 > RecDecrRawStat does not seem to work as intended > > > Key: TS-1632 > URL: https://issues.apache.org/jira/browse/TS-1632 > Project: Traffic Server > Issue Type: Bug > Components: Stats >Reporter: Yakov Kopel >Assignee: Leif Hedstrom > Fix For: 3.3.1 > > Attachments: dec_stats_sol_1.diff, dec_stats_sol_2.diff > > > In the RecDecrRawStat function (in I_RecProcess.h) there is a patch that > doesn't let the sum value to go beneath the zero value. > This can cause to a problem because the sum variable is per net-thread. > When the increase is done in one net-thread and the decrease is done in > another net-thread - the result will be 1 instead of 0. > First solution: > remove that patch > The problem with the First Solution: > If the TS-1631 fix will be in. When the TS will reset the stats, it can > cause to not positive values in the sum. this ca be when the reset is done > between an increase and decrease. > Second solution: > remove that patch > add a patch on the global sum (RecProcess.cc) and not for each net-thread > The problem with the First Solution: >It is similar to the problem with the first solution. The different is > that it won't show not negative values, but it can show lower value than the > real one. > anyone can think on a good solution? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1674) TSStatIntDecrement is broken
[ https://issues.apache.org/jira/browse/TS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583112#comment-13583112 ] Uri Shachar commented on TS-1674: - James -- You'd win your bet. I did the legwork on this and got the following results: 1) Switching to using global atomic variables *improves* performance by ~0.5% in ATS without plugins 2) In ATS with a simple plugin that does 20 increments/decrements of stat variables in 4 different hookpoints (80 calls total per transaction) I see a ~0.9% performance *degradation*. --> Once there are a lot of counters the memory barriers/collisions start to take a heavy toll I'll attach a patch for posterity, but considering these results I wouldn't recommend integrating it :-) > TSStatIntDecrement is broken > > > Key: TS-1674 > URL: https://issues.apache.org/jira/browse/TS-1674 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.3.1 > > > ATS keeps a thread-local copy of the stat value and aggregates it > periodically and on demand when stats are being collected. However the > decrement function doesn't let a value go negative. So in a thread that has > not incremented this stat previously, the decrement call "fails". This > negative value check is logically flawed as it doesn't account for the > per-thread distribution of the stats. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1674) TSStatIntDecrement is broken
[ https://issues.apache.org/jira/browse/TS-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1674: Attachment: remove_per_thread_stats.patch Adding a patch that removes per-thread stats (it isn't very clean) > TSStatIntDecrement is broken > > > Key: TS-1674 > URL: https://issues.apache.org/jira/browse/TS-1674 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 3.3.1 > > Attachments: remove_per_thread_stats.patch > > > ATS keeps a thread-local copy of the stat value and aggregates it > periodically and on demand when stats are being collected. However the > decrement function doesn't let a value go negative. So in a thread that has > not incremented this stat previously, the decrement call "fails". This > negative value check is logically flawed as it doesn't account for the > per-thread distribution of the stats. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1300) TSUrlStringGet appears to return incorrect URL for transparent HTTP requests
[ https://issues.apache.org/jira/browse/TS-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587792#comment-13587792 ] Uri Shachar commented on TS-1300: - You need to use TSHttpTxnEffectiveUrlStringGet instead of TSUrlStringGet if you want to get the full URL in a transparent deployment. Otherwise you'll get the URL sent by the client -- which won't have the hostname. > TSUrlStringGet appears to return incorrect URL for transparent HTTP requests > > > Key: TS-1300 > URL: https://issues.apache.org/jira/browse/TS-1300 > Project: Traffic Server > Issue Type: Bug > Components: TS API >Affects Versions: 3.0.2 > Environment: Centos 6.2 >Reporter: Domhnall Wildy >Assignee: Alan M. Carroll > Fix For: 3.3.2 > > > We have a plugin that uses the TSUrlStringGet method to retrieve the request > URL. When running TS as a non-transparent proxy the value returned by > TSUrlStringGet is the full URL for example: > http://www.somewebsite.com/something.html > However if I send requests transparently the value returned is: > http:///something.html > So it looks as if the host is ignored when the URL string is initially > created. I just wanted to check here to see if this could be an issue? Or > could the usage of the method be incorrect? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1058) Intercept an HTTP client's request
[
https://issues.apache.org/jira/browse/TS-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587825#comment-13587825
]
Uri Shachar commented on TS-1058:
-
That won't be enough -- we want to prevent the request from going upstream, so
we need to raise some sort of error from the plugin. As Yakov wrote in the
original description, we could use TSHttpTxnIntercept - but it forces a much
more complicated flow
> Intercept an HTTP client's request
> --
>
> Key: TS-1058
> URL: https://issues.apache.org/jira/browse/TS-1058
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Affects Versions: 3.1.1
>Reporter: Yakov Kopel
>Assignee: Leif Hedstrom
> Labels: patch
> Fix For: 3.3.2
>
> Attachments: patch.diff
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I want that the trafficserver will give the client the response instead of
> the server.
> The trafficserver offers the INKHttpTxnIntercept api to do so, but it is not
> so convenience to use it.
> I want to use the regular flow of the trafficserver, and its regular parsing
> commands.
> The trafficserver's plugins examples also aren't using the
> INKHttpTxnIntercept , but they rather using the "rasing error" method, and
> then they response the request at the response hook.
> So, this is whta i did.
> On the global-hook at the TS_EVENT_HTTP_READ_REQUEST_HDR i raised
> TS_EVENT_HTTP_ERROR.
> I also added TS_HTTP_SEND_RESPONSE_HDR_HOOK and there i returned http
> response with the KEEP-ALIVE header.
> The problem is that the trafficserver is closing the connection although i
> added to the response the KEEP-ALIVE header.
>
> When the Trafficserver is trying to send response to the client, it terminate
> the session after it.
> Although I added the "KEEP-ALIVE" mime field - it didn't work.
> The debug dump is looking like this:
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::state_api_callback, HTTP_API_CONTINUE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::state_api_callout, HTTP_API_CONTINUE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpSM::do_redirect]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpTunnel::deallocate_postdata_copy_buffers]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> adding producer 'internal msg'
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> adding consumer 'user agent'
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel)
> tunnel_run started, p_arg is NULL
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_tunnel) [4]
> consumer_handler [user agent VC_EVENT_WRITE_COMPLETE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::tunnel_handler_ua, VC_EVENT_WRITE_COMPLETE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
> closed
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_cs) [4] session
> destroy
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [HttpSM::main_handler, HTTP_TUNNEL_EVENT_DONE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4]
> [&HttpSM::tunnel_handler, HTTP_TUNNEL_EVENT_DONE]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http_redirect)
> [HttpTunnel::deallocate_postdata_copy_buffers]
> [Dec 15 07:46:47.251] Server {0x2b8806ac9a80} DEBUG: (http) [4] calling
> plugin on hook TS_HTTP_TXN_CLOSE_HOOK at hook 0x3B97610
> The Solution:
> I'm adding a patch of functino that rasing the internal flag of KEEP-ALIVE,
> so the trafficserver will realy believe us that we want to keep this
> connection alive :)
> Example for the usage of the new function:
> // Tell the trafficserver to not close this connection (keep-alive)
> TSHttpTxnCloseAfterResponse(txnp, 0);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TS-1300) TSUrlStringGet appears to return incorrect URL for transparent HTTP requests
[
https://issues.apache.org/jira/browse/TS-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588442#comment-13588442
]
Uri Shachar edited comment on TS-1300 at 2/27/13 3:39 PM:
--
Sure, maybe consider adding a comment to the header to point folks in the right
direction.
{code:title=ts.h.in|borderStyle=solid}
diff --git a/proxy/api/ts/ts.h.in b/proxy/api/ts/ts.h.in
index f1d5982..0860de0 100644
--- a/proxy/api/ts/ts.h.in
+++ b/proxy/api/ts/ts.h.in
@@ -1388,6 +1388,7 @@ extern "C"
call to TSmalloc(). It should be freed by a call to TSfree().
The length parameter must present, providing storage for the URL
string length value.
+ Note: To get the effective URL from a request, use
TSHttpTxnEffectiveUrlStringGet
@param bufp marshal buffer containing the URL you want to get.
@param offset location of the URL within bufp.
{code}
was (Author: ushachar):
Sure, maybe consider adding a comment to the header to point folks to the
right direction.
{code:title=ts.h.in|borderStyle=solid}
diff --git a/proxy/api/ts/ts.h.in b/proxy/api/ts/ts.h.in
index f1d5982..0860de0 100644
--- a/proxy/api/ts/ts.h.in
+++ b/proxy/api/ts/ts.h.in
@@ -1388,6 +1388,7 @@ extern "C"
call to TSmalloc(). It should be freed by a call to TSfree().
The length parameter must present, providing storage for the URL
string length value.
+ Note: To get the effective URL from a request, use
TSHttpTxnEffectiveUrlStringGet
@param bufp marshal buffer containing the URL you want to get.
@param offset location of the URL within bufp.
{code}
> TSUrlStringGet appears to return incorrect URL for transparent HTTP requests
>
>
> Key: TS-1300
> URL: https://issues.apache.org/jira/browse/TS-1300
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Affects Versions: 3.0.2
> Environment: Centos 6.2
>Reporter: Domhnall Wildy
>Assignee: Alan M. Carroll
> Fix For: 3.3.2
>
>
> We have a plugin that uses the TSUrlStringGet method to retrieve the request
> URL. When running TS as a non-transparent proxy the value returned by
> TSUrlStringGet is the full URL for example:
> http://www.somewebsite.com/something.html
> However if I send requests transparently the value returned is:
> http:///something.html
> So it looks as if the host is ignored when the URL string is initially
> created. I just wanted to check here to see if this could be an issue? Or
> could the usage of the method be incorrect?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1300) TSUrlStringGet appears to return incorrect URL for transparent HTTP requests
[
https://issues.apache.org/jira/browse/TS-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588442#comment-13588442
]
Uri Shachar commented on TS-1300:
-
Sure, maybe consider adding a comment to the header to point folks to the right
direction.
{code:title=ts.h.in|borderStyle=solid}
diff --git a/proxy/api/ts/ts.h.in b/proxy/api/ts/ts.h.in
index f1d5982..0860de0 100644
--- a/proxy/api/ts/ts.h.in
+++ b/proxy/api/ts/ts.h.in
@@ -1388,6 +1388,7 @@ extern "C"
call to TSmalloc(). It should be freed by a call to TSfree().
The length parameter must present, providing storage for the URL
string length value.
+ Note: To get the effective URL from a request, use
TSHttpTxnEffectiveUrlStringGet
@param bufp marshal buffer containing the URL you want to get.
@param offset location of the URL within bufp.
{code}
> TSUrlStringGet appears to return incorrect URL for transparent HTTP requests
>
>
> Key: TS-1300
> URL: https://issues.apache.org/jira/browse/TS-1300
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Affects Versions: 3.0.2
> Environment: Centos 6.2
>Reporter: Domhnall Wildy
>Assignee: Alan M. Carroll
> Fix For: 3.3.2
>
>
> We have a plugin that uses the TSUrlStringGet method to retrieve the request
> URL. When running TS as a non-transparent proxy the value returned by
> TSUrlStringGet is the full URL for example:
> http://www.somewebsite.com/something.html
> However if I send requests transparently the value returned is:
> http:///something.html
> So it looks as if the host is ignored when the URL string is initially
> created. I just wanted to check here to see if this could be an issue? Or
> could the usage of the method be incorrect?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-921) TSIOBufferBlockReadStart() could'nt return the corresponding chunk data length when original server using the "Transfer Encoding: chunked" http header !
[
https://issues.apache.org/jira/browse/TS-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593216#comment-13593216
]
Uri Shachar commented on TS-921:
This can probably be closed -- As William wrote in the initial comment,
dechunking happens before the transform receives the data
> TSIOBufferBlockReadStart() could'nt return the corresponding chunk data
> length when original server using the "Transfer Encoding: chunked" http
> header !
>
>
> Key: TS-921
> URL: https://issues.apache.org/jira/browse/TS-921
> Project: Traffic Server
> Issue Type: Bug
> Components: TS API
>Affects Versions: 3.0.1
> Environment: OS: Ubuntu 10.10 32bit, Traffic Server version:.3.0.1,
> Web Browser：firefox 6.0，CPU: Intel core i3-2100 3.10GHz, Memory: 2G,
> HardDisk: 500G
>Reporter: taoyunxing
> Labels: transfer_encoding_chunded
> Fix For: 3.3.2
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> Recently I meet with a strange proble when I manage to get the server
> response body in the "Transfer Encoding: chunked" mode:
> I couldn't get the corresponding chunk length in hexdecimal ! The details as
> follows:
> I use the "null-transform" plugin modified to just output the server response
> body, when the web server uses the "Transfer Encoding: chunked" header
> to transfer chunked data to user agent, eg, I request the web page:
> "http://www.qq.com/";, I just get the chunk body data, but get no chunk length
> in
> the hexdecimal format "383cb\r\n" before the chunk body data. the chunk body
> data is uncompressed and like as " 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>\r\n..."
> In addition, I capture the data packet using the Wireshark software, I sure
> that I see the chunk length "383cb\r\n" before the chunk body data
> " "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>\r\n...", it is
> a complete chunk response !
> I continue to check the code of null-transform.c, set a breakpoint at the
> function TSIOBufferBlockReadStart(), run ATS and debug it, when ATS stop at
> the breakpoint TSIOBufferBlockReadStart(), I print the return string of
> TSIOBufferBlockReadStart(), there is no chunk data length at the head of
> output string, which implies the api TSIOBufferBlockReadStart() has bug！
> Breakpoint 1, TSIOBufferBlockReadStart (blockp=0x89d6570, readerp=0x89d5330,
> avail=0xb6c8e288) at InkIOCoreAPI.cc:659
> 659 {
> (gdb) s
> 660 sdk_assert(sdk_sanity_check_iocore_structure(blockp) == TS_SUCCESS);
> (gdb) n
> 667 p = blk->start();
> (gdb)
> 668 if (avail)
> (gdb) p p
> $3 = 0xb1312000 " Transitional//EN\"
> \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\";>\r\n xmlns=\"http://www.w3.org/1999/xhtml\";>\r\n\r\n http-equiv=\"Conten"...
> (gdb)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1627) Support requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593779#comment-13593779 ] Uri Shachar commented on TS-1627: - Bryan -- Could you take a look at this? Let me know if you want me to rebase it to latest trunk. > Support requests with payload > - > > Key: TS-1627 > URL: https://issues.apache.org/jira/browse/TS-1627 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: Uri Shachar >Assignee: Bryan Call > Fix For: 3.3.1 > > Attachments: get_with_payload.patch, requests_with_content.patch > > > From what I understand from RFC 2616, these requests should be legal. ATS > currently accepts these requests, but drops the body when passing them onward > to the upstream. > Most discussion that I could find on the web say that this is legal -- > although what the upstream can actually do with the payload isn't clear > http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html > http://tech.groups.yahoo.com/group/rest-discuss/message/9957 > http://stackoverflow.com/questions/978061/http-get-with-request-body > http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1626) remove WUTS proxy code
[ https://issues.apache.org/jira/browse/TS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1626: Attachment: remove_wuts_and_spider.patch Remove WUTS and spider crud > remove WUTS proxy code > -- > > Key: TS-1626 > URL: https://issues.apache.org/jira/browse/TS-1626 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: James Peach > Attachments: remove_wuts_and_spider.patch > > > There is a bunch of code doing something with "WUTS proxy status codes". What > is a WUTS and why do we care? If this is cruft, let's get rid of it! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1626) remove WUTS proxy code
[ https://issues.apache.org/jira/browse/TS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1626: Attachment: (was: remove_wuts_and_spider.patch) > remove WUTS proxy code > -- > > Key: TS-1626 > URL: https://issues.apache.org/jira/browse/TS-1626 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: James Peach > > There is a bunch of code doing something with "WUTS proxy status codes". What > is a WUTS and why do we care? If this is cruft, let's get rid of it! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1626) remove WUTS proxy code
[ https://issues.apache.org/jira/browse/TS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1626: Attachment: remove_wuts_and_spider.patch sigh forgot to adjust array init size when removing elements Attaching fixed version > remove WUTS proxy code > -- > > Key: TS-1626 > URL: https://issues.apache.org/jira/browse/TS-1626 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: James Peach > Attachments: remove_wuts_and_spider.patch > > > There is a bunch of code doing something with "WUTS proxy status codes". What > is a WUTS and why do we care? If this is cruft, let's get rid of it! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1627) Support requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1627: Attachment: requests_with_content_rebased.patch Rebased to current head: bd5816b4b73529d6fbbb1bd2668f85f69a4699e8 (needed integration with the fix for TS-1155) > Support requests with payload > - > > Key: TS-1627 > URL: https://issues.apache.org/jira/browse/TS-1627 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: Uri Shachar >Assignee: Bryan Call > Fix For: 3.3.2 > > Attachments: get_with_payload.patch, requests_with_content.patch, > requests_with_content_rebased.patch > > > From what I understand from RFC 2616, these requests should be legal. ATS > currently accepts these requests, but drops the body when passing them onward > to the upstream. > Most discussion that I could find on the web say that this is legal -- > although what the upstream can actually do with the payload isn't clear > http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html > http://tech.groups.yahoo.com/group/rest-discuss/message/9957 > http://stackoverflow.com/questions/978061/http-get-with-request-body > http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1633) add new stat sync type: TS_STAT_SYNC_MAX
[ https://issues.apache.org/jira/browse/TS-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar reassigned TS-1633: --- Assignee: Uri Shachar > add new stat sync type: TS_STAT_SYNC_MAX > > > Key: TS-1633 > URL: https://issues.apache.org/jira/browse/TS-1633 > Project: Traffic Server > Issue Type: Bug > Components: Stats >Reporter: Yakov Kopel >Assignee: Uri Shachar > Fix For: 3.3.4 > > Attachments: stat_max_ver_1.diff > > > Adding a new stat sync type - max. > This is a good type of stat to find peaks in the stats. > It can be very useful with the stat clear api (after the fix - TS-1631). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1256) Streamline usage of PATH_NAME_MAX
[
https://issues.apache.org/jira/browse/TS-1256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uri Shachar updated TS-1256:
Description:
There are right now two different usages of the constant {{PATH_NAME_MAX}} in
variable declarations:
{code}
char foo[PATH_NAME_MAX];
{code}
and
{code}
char bar[PATH_NAME_MAX + 1];
{code}
Since we define what {{PATH_NAME_MAX}} is ourselves, we should streamline our
code to only use the first kind of declaration.
was:
There are right now two different usages of the constant {{PATH_NAME_MAX}} in
variable declarations:
{code:c}
char foo[PATH_NAME_MAX];
{code}
and
{code:c}
char bar[PATH_NAME_MAX + 1];
{code}
Since we define what {{PATH_NAME_MAX}} is ourselves, we should streamline our
code to only use the first kind of declaration.
> Streamline usage of PATH_NAME_MAX
> -
>
> Key: TS-1256
> URL: https://issues.apache.org/jira/browse/TS-1256
> Project: Traffic Server
> Issue Type: Task
> Components: Cleanup
>Reporter: Igor Galić
> Fix For: 3.5.0
>
>
> There are right now two different usages of the constant {{PATH_NAME_MAX}} in
> variable declarations:
> {code}
> char foo[PATH_NAME_MAX];
> {code}
> and
> {code}
> char bar[PATH_NAME_MAX + 1];
> {code}
> Since we define what {{PATH_NAME_MAX}} is ourselves, we should streamline our
> code to only use the first kind of declaration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1627) Support requests with payload
[ https://issues.apache.org/jira/browse/TS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1627: Assignee: Uri Shachar (was: Bryan Call) > Support requests with payload > - > > Key: TS-1627 > URL: https://issues.apache.org/jira/browse/TS-1627 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.3.0 >Reporter: Uri Shachar >Assignee: Uri Shachar > Fix For: 3.3.2 > > Attachments: get_with_payload.patch, requests_with_content.patch, > requests_with_content_rebased.patch > > > From what I understand from RFC 2616, these requests should be legal. ATS > currently accepts these requests, but drops the body when passing them onward > to the upstream. > Most discussion that I could find on the web say that this is legal -- > although what the upstream can actually do with the payload isn't clear > http://lists.w3.org/Archives/Public/ietf-http-wg/2006AprJun/0096.html > http://tech.groups.yahoo.com/group/rest-discuss/message/9957 > http://stackoverflow.com/questions/978061/http-get-with-request-body > http://dret.typepad.com/dretblog/2007/10/http-get-with-m.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1717) static library build fails with duplicate symbols
[ https://issues.apache.org/jira/browse/TS-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar reassigned TS-1717: --- Assignee: Uri Shachar (was: James Peach) > static library build fails with duplicate symbols > - > > Key: TS-1717 > URL: https://issues.apache.org/jira/browse/TS-1717 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: Uri Shachar > Fix For: 3.3.2 > > > fish:trafficserver.git jpeach$ ./config.nice --disable-shared --enable-static > && make -j && sudo make install > ... > CXXLDtraffic_manager > AR libmgmt_p.a > duplicate symbol _diags in: > Main.o > ../lib/ts/.libs/libtsutil.a(Diags.o) > ld: 1 duplicate symbol for architecture x86_64 > example/app-template/app-template.cc://Diags *diags = NULL; > iocore/aio/test_AIO.i:Diags *diags; > iocore/cluster/test_I_Cluster.cc:Diags *diags; > iocore/cluster/test_P_Cluster.cc:Diags *diags; > iocore/dns/test_I_DNS.cc:Diags *diags; > iocore/dns/test_P_DNS.cc:Diags *diags; > iocore/eventsystem/test_Buffer.cc:Diags *diags; > iocore/eventsystem/test_Event.i:Diags *diags; > iocore/hostdb/test_I_HostDB.cc:Diags *diags; > iocore/hostdb/test_P_HostDB.cc:Diags *diags; > iocore/net/test_I_Net.cc:Diags *diags; > iocore/net/test_I_UDPNet.cc:Diags *diags; > iocore/net/test_P_Net.cc:Diags *diags; > iocore/net/test_P_UDPNet.cc:Diags *diags; > iocore/utils/diags.i://Diags *diags; > lib/records/I_RecCore.h:int RecSetDiags(Diags * diags); > lib/records/I_RecLocal.h:int RecLocalInit(Diags * diags = NULL); > lib/records/I_RecProcess.h:int RecProcessInit(RecModeT mode_type, Diags * > diags = NULL); > lib/records/P_RecCore.h:int RecCoreInit(RecModeT mode_type, Diags * diags); > lib/records/RecCore.cc:Diags *g_diags = NULL; > lib/records/RecCore.cc:RecCoreInit(RecModeT mode_type, Diags *_diags) > lib/records/RecCore.cc:RecSetDiags(Diags * _diags) > lib/records/RecLocal.cc:RecLocalInit(Diags * _diags) > lib/records/RecProcess.cc:RecProcessInit(RecModeT mode_type, Diags *_diags) > lib/records/RecUtils.cc:extern Diags *g_diags; > lib/records/test_I_RecLocal.cc:Diags *diags = NULL; > lib/records/test_RecProcess.i:Diags *diags = NULL; > lib/ts/Diags.cc:inkcoreapi Diags *diags = NULL; > lib/ts/Diags.h:extern inkcoreapi Diags *diags; > mgmt/Main.cc:inkcoreapi Diags *diags; > proxy/DiagsConfig.h: Diags *diags; > proxy/Initialize.h:extern Diags *diags; > proxy/Main.cc://inkcoreapi Diags *diags = NULL; > proxy/hdrs/load_http_hdr.cc://Diags *diags; > proxy/logging/LogStandalone.cc:Diags *diags = NULL; > Additionally, AFAICT diags.i is not used and can be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1717) static library build fails with duplicate symbols
[ https://issues.apache.org/jira/browse/TS-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1717: Assignee: James Peach (was: Uri Shachar) > static library build fails with duplicate symbols > - > > Key: TS-1717 > URL: https://issues.apache.org/jira/browse/TS-1717 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.2 > > > fish:trafficserver.git jpeach$ ./config.nice --disable-shared --enable-static > && make -j && sudo make install > ... > CXXLDtraffic_manager > AR libmgmt_p.a > duplicate symbol _diags in: > Main.o > ../lib/ts/.libs/libtsutil.a(Diags.o) > ld: 1 duplicate symbol for architecture x86_64 > example/app-template/app-template.cc://Diags *diags = NULL; > iocore/aio/test_AIO.i:Diags *diags; > iocore/cluster/test_I_Cluster.cc:Diags *diags; > iocore/cluster/test_P_Cluster.cc:Diags *diags; > iocore/dns/test_I_DNS.cc:Diags *diags; > iocore/dns/test_P_DNS.cc:Diags *diags; > iocore/eventsystem/test_Buffer.cc:Diags *diags; > iocore/eventsystem/test_Event.i:Diags *diags; > iocore/hostdb/test_I_HostDB.cc:Diags *diags; > iocore/hostdb/test_P_HostDB.cc:Diags *diags; > iocore/net/test_I_Net.cc:Diags *diags; > iocore/net/test_I_UDPNet.cc:Diags *diags; > iocore/net/test_P_Net.cc:Diags *diags; > iocore/net/test_P_UDPNet.cc:Diags *diags; > iocore/utils/diags.i://Diags *diags; > lib/records/I_RecCore.h:int RecSetDiags(Diags * diags); > lib/records/I_RecLocal.h:int RecLocalInit(Diags * diags = NULL); > lib/records/I_RecProcess.h:int RecProcessInit(RecModeT mode_type, Diags * > diags = NULL); > lib/records/P_RecCore.h:int RecCoreInit(RecModeT mode_type, Diags * diags); > lib/records/RecCore.cc:Diags *g_diags = NULL; > lib/records/RecCore.cc:RecCoreInit(RecModeT mode_type, Diags *_diags) > lib/records/RecCore.cc:RecSetDiags(Diags * _diags) > lib/records/RecLocal.cc:RecLocalInit(Diags * _diags) > lib/records/RecProcess.cc:RecProcessInit(RecModeT mode_type, Diags *_diags) > lib/records/RecUtils.cc:extern Diags *g_diags; > lib/records/test_I_RecLocal.cc:Diags *diags = NULL; > lib/records/test_RecProcess.i:Diags *diags = NULL; > lib/ts/Diags.cc:inkcoreapi Diags *diags = NULL; > lib/ts/Diags.h:extern inkcoreapi Diags *diags; > mgmt/Main.cc:inkcoreapi Diags *diags; > proxy/DiagsConfig.h: Diags *diags; > proxy/Initialize.h:extern Diags *diags; > proxy/Main.cc://inkcoreapi Diags *diags = NULL; > proxy/hdrs/load_http_hdr.cc://Diags *diags; > proxy/logging/LogStandalone.cc:Diags *diags = NULL; > Additionally, AFAICT diags.i is not used and can be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1708) Using tr-pass port option causes requests with large headers to hang
[ https://issues.apache.org/jira/browse/TS-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1708: Assignee: Uri Shachar (was: Alan M. Carroll) > Using tr-pass port option causes requests with large headers to hang > > > Key: TS-1708 > URL: https://issues.apache.org/jira/browse/TS-1708 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Uri Shachar >Assignee: Uri Shachar > Fix For: 3.3.2 > > Attachments: transparent_passthrough_hang.diff > > > When tr-pass is enabled and a request comes in on a new connection with total > size of request headers > 4K it will hang in the parser (and never time out). > In order to support tr-pass, we clone the ua_buffer_reader, but until the > parser decides the request is valid/invalid, we do not consume data from the > clone. Eventually, the underlying iobuffer fills up and the parser won't be > called with the rest of the pending data. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1423) Blind tunneling of garbage/invalid requests when using transparent interception
[ https://issues.apache.org/jira/browse/TS-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13610350#comment-13610350 ] Uri Shachar commented on TS-1423: - Alan - Can I close this? > Blind tunneling of garbage/invalid requests when using transparent > interception > --- > > Key: TS-1423 > URL: https://issues.apache.org/jira/browse/TS-1423 > Project: Traffic Server > Issue Type: New Feature >Affects Versions: 3.2.0 > Environment: 3.2 with TProxy inteception and > proxy.config.http.use_client_target_addr == 1 >Reporter: B Wyatt >Assignee: Alan M. Carroll > Fix For: 3.3.4 > > Attachments: transparent_passthrough_as_port_option.diff, > transparent_passthrough.diff > > > Presently, when ATS encounters a request that it cannot parse or that is > malformed in any way, it sends an error response to the client. > When using transparent interception and > proxy.config.http.use_client_target_addr ATS should have enough information > to blindly tunnel the original "transmission" to the desired endpoint and > maintain the service regardless of HTTP/1.x compliance and moreover if it is > non-HTTP communication over port 80. > Bonus would be support for supporting alien protocols where the server speaks > first however, ambiguity over a slow incoming request and an expectation that > the server speaks first can make that difficult. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13610396#comment-13610396 ] Uri Shachar commented on TS-1125: - AFAIK -- no browsers actually use "Expect: 100-Continue", but many other clients do (for example, cURL, .NET clients, adobe downloaders when not configured with explicit proxy...) It's quite hard to implement support for this correctly in a proxy perspective (Squid didn't support this until 3.2) - If you return a 100-Continue immediately (regardless of upstream), you run into issues if the upstream refuses the request Note that according to the RFC, clients which have seen a 100-Continue response from a particular upstream are allowed to hang indefinitely while waiting for the response -- if they haven't seen such a response in the past they "SHOULD NOT"... > POST's with Expect: 100-continue are slowed by delayed 100 response. > > > Key: TS-1125 > URL: https://issues.apache.org/jira/browse/TS-1125 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.0.2 > Environment: TS 3.0.2 going to Apache 2.2 web server >Reporter: William Bardwell >Priority: Minor > Fix For: 3.3.3 > > > Sending a post like: > POST / HTTP/1.1 > Host: www.example.com > Content-Length: 10 > Expect: 100-continue > directly to the web server immediately sends back: > HTTP/1.1 100 Continue > And then when the post data is sent, a status 200 response comes back. > But when going through ATS the "HTTP/1.1 100 Continue" is not sent > immediately, and instead is sent after the POST data has been received. This > is legal, but it makes clients that are hoping for a 100 continue to wait a > little while hoping to get that, ATS should forward that response through > immediately. > Note: I see curl using "Expect: 100-continue" with > 1024 bytes of post data, > but web searching indicates that some Microsoft products also use it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1403) f_inbound_transparency is not handled by all accept cases
[ https://issues.apache.org/jira/browse/TS-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uri Shachar updated TS-1403: Assignee: Uri Shachar > f_inbound_transparency is not handled by all accept cases > - > > Key: TS-1403 > URL: https://issues.apache.org/jira/browse/TS-1403 > Project: Traffic Server > Issue Type: Bug > Components: Network >Affects Versions: 3.2.0 >Reporter: Yossi Gottlieb >Assignee: Uri Shachar >Priority: Minor > Fix For: sometime > > Attachments: transparency.diff > > > The inbound transparency flag does not always take affect, depending on the > accept configuration. This is not currently an issue because TSAPI doesn't > provide a standard transparent accept API, but it will become an issue once > the interface is created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1717) static library build fails with duplicate symbols
[ https://issues.apache.org/jira/browse/TS-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613324#comment-13613324 ] Uri Shachar commented on TS-1717: - I've had a go at this -- didn't end well :-( Getting just libtsutil in statically is easy enough -- getting a clean, completely static build is a different story. In any case, a first step would be to remove the AC_DISABLE_STATIC from configure.ac -- I missed it and spent hours trying to figure out why libtool was ignoring me > static library build fails with duplicate symbols > - > > Key: TS-1717 > URL: https://issues.apache.org/jira/browse/TS-1717 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.2 > > > fish:trafficserver.git jpeach$ ./config.nice --disable-shared --enable-static > && make -j && sudo make install > ... > CXXLDtraffic_manager > AR libmgmt_p.a > duplicate symbol _diags in: > Main.o > ../lib/ts/.libs/libtsutil.a(Diags.o) > ld: 1 duplicate symbol for architecture x86_64 > example/app-template/app-template.cc://Diags *diags = NULL; > iocore/aio/test_AIO.i:Diags *diags; > iocore/cluster/test_I_Cluster.cc:Diags *diags; > iocore/cluster/test_P_Cluster.cc:Diags *diags; > iocore/dns/test_I_DNS.cc:Diags *diags; > iocore/dns/test_P_DNS.cc:Diags *diags; > iocore/eventsystem/test_Buffer.cc:Diags *diags; > iocore/eventsystem/test_Event.i:Diags *diags; > iocore/hostdb/test_I_HostDB.cc:Diags *diags; > iocore/hostdb/test_P_HostDB.cc:Diags *diags; > iocore/net/test_I_Net.cc:Diags *diags; > iocore/net/test_I_UDPNet.cc:Diags *diags; > iocore/net/test_P_Net.cc:Diags *diags; > iocore/net/test_P_UDPNet.cc:Diags *diags; > iocore/utils/diags.i://Diags *diags; > lib/records/I_RecCore.h:int RecSetDiags(Diags * diags); > lib/records/I_RecLocal.h:int RecLocalInit(Diags * diags = NULL); > lib/records/I_RecProcess.h:int RecProcessInit(RecModeT mode_type, Diags * > diags = NULL); > lib/records/P_RecCore.h:int RecCoreInit(RecModeT mode_type, Diags * diags); > lib/records/RecCore.cc:Diags *g_diags = NULL; > lib/records/RecCore.cc:RecCoreInit(RecModeT mode_type, Diags *_diags) > lib/records/RecCore.cc:RecSetDiags(Diags * _diags) > lib/records/RecLocal.cc:RecLocalInit(Diags * _diags) > lib/records/RecProcess.cc:RecProcessInit(RecModeT mode_type, Diags *_diags) > lib/records/RecUtils.cc:extern Diags *g_diags; > lib/records/test_I_RecLocal.cc:Diags *diags = NULL; > lib/records/test_RecProcess.i:Diags *diags = NULL; > lib/ts/Diags.cc:inkcoreapi Diags *diags = NULL; > lib/ts/Diags.h:extern inkcoreapi Diags *diags; > mgmt/Main.cc:inkcoreapi Diags *diags; > proxy/DiagsConfig.h: Diags *diags; > proxy/Initialize.h:extern Diags *diags; > proxy/Main.cc://inkcoreapi Diags *diags = NULL; > proxy/hdrs/load_http_hdr.cc://Diags *diags; > proxy/logging/LogStandalone.cc:Diags *diags = NULL; > Additionally, AFAICT diags.i is not used and can be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1717) static library build fails with duplicate symbols
[ https://issues.apache.org/jira/browse/TS-1717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616194#comment-13616194 ] Uri Shachar commented on TS-1717: - Cool -- Where is the patch? > static library build fails with duplicate symbols > - > > Key: TS-1717 > URL: https://issues.apache.org/jira/browse/TS-1717 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach >Assignee: James Peach > Fix For: 3.3.2 > > > fish:trafficserver.git jpeach$ ./config.nice --disable-shared --enable-static > && make -j && sudo make install > ... > CXXLDtraffic_manager > AR libmgmt_p.a > duplicate symbol _diags in: > Main.o > ../lib/ts/.libs/libtsutil.a(Diags.o) > ld: 1 duplicate symbol for architecture x86_64 > example/app-template/app-template.cc://Diags *diags = NULL; > iocore/aio/test_AIO.i:Diags *diags; > iocore/cluster/test_I_Cluster.cc:Diags *diags; > iocore/cluster/test_P_Cluster.cc:Diags *diags; > iocore/dns/test_I_DNS.cc:Diags *diags; > iocore/dns/test_P_DNS.cc:Diags *diags; > iocore/eventsystem/test_Buffer.cc:Diags *diags; > iocore/eventsystem/test_Event.i:Diags *diags; > iocore/hostdb/test_I_HostDB.cc:Diags *diags; > iocore/hostdb/test_P_HostDB.cc:Diags *diags; > iocore/net/test_I_Net.cc:Diags *diags; > iocore/net/test_I_UDPNet.cc:Diags *diags; > iocore/net/test_P_Net.cc:Diags *diags; > iocore/net/test_P_UDPNet.cc:Diags *diags; > iocore/utils/diags.i://Diags *diags; > lib/records/I_RecCore.h:int RecSetDiags(Diags * diags); > lib/records/I_RecLocal.h:int RecLocalInit(Diags * diags = NULL); > lib/records/I_RecProcess.h:int RecProcessInit(RecModeT mode_type, Diags * > diags = NULL); > lib/records/P_RecCore.h:int RecCoreInit(RecModeT mode_type, Diags * diags); > lib/records/RecCore.cc:Diags *g_diags = NULL; > lib/records/RecCore.cc:RecCoreInit(RecModeT mode_type, Diags *_diags) > lib/records/RecCore.cc:RecSetDiags(Diags * _diags) > lib/records/RecLocal.cc:RecLocalInit(Diags * _diags) > lib/records/RecProcess.cc:RecProcessInit(RecModeT mode_type, Diags *_diags) > lib/records/RecUtils.cc:extern Diags *g_diags; > lib/records/test_I_RecLocal.cc:Diags *diags = NULL; > lib/records/test_RecProcess.i:Diags *diags = NULL; > lib/ts/Diags.cc:inkcoreapi Diags *diags = NULL; > lib/ts/Diags.h:extern inkcoreapi Diags *diags; > mgmt/Main.cc:inkcoreapi Diags *diags; > proxy/DiagsConfig.h: Diags *diags; > proxy/Initialize.h:extern Diags *diags; > proxy/Main.cc://inkcoreapi Diags *diags = NULL; > proxy/hdrs/load_http_hdr.cc://Diags *diags; > proxy/logging/LogStandalone.cc:Diags *diags = NULL; > Additionally, AFAICT diags.i is not used and can be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1786) only enable -Werror for debug builds
[ https://issues.apache.org/jira/browse/TS-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13616574#comment-13616574 ] Uri Shachar commented on TS-1786: - I'm concerned that this will make it too easy to miss/ignore problems -- how many people build with _--enable-debug_ before each commit? Out of the rest, how many would notice that the debug buildbot is failing. I'd suggest adding a configure.ac option to disable -Werror (something like _\--disable-werror_) - that way *all* of our buildbots will still be sensitive to compilation warnings, but users will be able to override if it causes breakage on their system. > only enable -Werror for debug builds > > > Key: TS-1786 > URL: https://issues.apache.org/jira/browse/TS-1786 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: James Peach > Fix For: 3.3.3 > > > It's very difficult to always build with -Werror on every platform we > support. -Werror is only valuable to developers, not so much for users. We > should consider only enabling -Werror if the build was configured with > --enable-debug. This probably involves adding autoconf macros to test whether > the compiler actually supports -Werror. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620251#comment-13620251 ] Uri Shachar commented on TS-1125: - Sure -- adding a knob would be better then what we currently have. > POST's with Expect: 100-continue are slowed by delayed 100 response. > > > Key: TS-1125 > URL: https://issues.apache.org/jira/browse/TS-1125 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 3.0.2 > Environment: TS 3.0.2 going to Apache 2.2 web server >Reporter: William Bardwell >Priority: Minor > Fix For: 3.3.3 > > > Sending a post like: > POST / HTTP/1.1 > Host: www.example.com > Content-Length: 10 > Expect: 100-continue > directly to the web server immediately sends back: > HTTP/1.1 100 Continue > And then when the post data is sent, a status 200 response comes back. > But when going through ATS the "HTTP/1.1 100 Continue" is not sent > immediately, and instead is sent after the POST data has been received. This > is legal, but it makes clients that are hoping for a 100 continue to wait a > little while hoping to get that, ATS should forward that response through > immediately. > Note: I see curl using "Expect: 100-continue" with > 1024 bytes of post data, > but web searching indicates that some Microsoft products also use it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1496) Traffic Server with null-transform buffering large responses when client connection slow
[
https://issues.apache.org/jira/browse/TS-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620324#comment-13620324
]
Uri Shachar commented on TS-1496:
-
Still looking into this patch -- but a couple of questions/comments:
1) Doesn't really matter, but in P_IOBuffer.h
IOBufferReader::is_read_avail_more_than, wouldn't it be cleaner to set
t=block_read_avail() initially, instead of using the start_offset (probably
also true for IOBufferReader::read_avail)?
2) What would be the use-case for a plugin to register a transform on
TS_HTTP_RESPONSE_CLIENT_HOOK?
3) What about the opposite use-case, where fast client uploads a large POST to
a slow server? Different JIRA?
> Traffic Server with null-transform buffering large responses when client
> connection slow
>
>
> Key: TS-1496
> URL: https://issues.apache.org/jira/browse/TS-1496
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Affects Versions: 3.2.0
> Environment: Red Hat 6.3
>Reporter: snf
>Assignee: Alan M. Carroll
> Fix For: 3.3.2
>
> Attachments: ts-1496.diff, TS-1496.patch, TS-1496.patch
>
>
> Scenario: Traffic Server started with the null-transform plugin. The link
> between the client and Traffic Server is slower than the link between the
> Traffic Server and the Origin Server.
> Affect: If the client requests a large file from the Origin Server, the
> whole file can be transmitted to, and buffered by, Traffic Server before
> content is released to the client. This is a bigger issue if a large number
> of clients request large files then the Traffic Server could end up buffering
> very large amounts of content.
> Expected behaviour: The Traffic Server should not download all the content
> from the Origin Server. Instead, if the client is slow receiving from
> Traffic Server, then Traffic Server should be slow receiving from the Origin
> Server. Traffic Server should facilitate end to end flow control between
> client and Origin Server.
> Tools to replicate problem: Use Traffic Control to set a lower bandwidth on
> the client machine.
> Possible related area in the Traffic Server code: The following comment
> appears in proxy/http/Httptunnel.cc
> 48 static void
> 49 chunked_reenable(HttpTunnelProducer * p, HttpTunnel * tunnel)
> 50 {
> 51
> 52 // FIX ME: still need to deal with huge chunk sizes. If a chunk
> 53 // is 1GB, we will currently buffer the whole thing
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
