[jira] [Updated] (TS-1475) static analysis: clean up all clang and coverity reports
[ https://issues.apache.org/jira/browse/TS-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-1475: Description: the new report is in https://ci.trafficserver.apache.org/files/clang-analyzer/latest/ (was: the new report is in http://people.apache.org/~igalic/checks/ats/latest/ and I will open more sub tasks) static analysis: clean up all clang and coverity reports Key: TS-1475 URL: https://issues.apache.org/jira/browse/TS-1475 Project: Traffic Server Issue Type: Bug Components: Cleanup Affects Versions: 3.3.0 Reporter: Zhao Yongming Fix For: sometime the new report is in https://ci.trafficserver.apache.org/files/clang-analyzer/latest/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1146) RFC 5077 TLS Session tickets
[ https://issues.apache.org/jira/browse/TS-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14071797#comment-14071797 ] ASF GitHub Bot commented on TS-1146: Github user asfgit closed the pull request at: https://github.com/apache/trafficserver/pull/96 RFC 5077 TLS Session tickets Key: TS-1146 URL: https://issues.apache.org/jira/browse/TS-1146 Project: Traffic Server Issue Type: New Feature Components: SSL Reporter: James Peach Assignee: James Peach Labels: A Fix For: 4.2.0 Attachments: SSL_CTX_set_tlsext_ticket_key_cb.txt, session_ticket.patch, session_ticket_review.patch For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the machines need to have the same server ticket. See https://github.com/apache/httpd rev 967d943b93498233f0ec81a5b48706fdb6892dfd -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
Nikolai Gorchilov created TS-2954: - Summary: cache poisoning due to proxy.config.http.use_client_target_addr = 1 Key: TS-2954 URL: https://issues.apache.org/jira/browse/TS-2954 Project: Traffic Server Issue Type: Bug Components: Cache, DNS Reporter: Nikolai Gorchilov Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid cache poisoning, while serving the fake response to the client. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolai Gorchilov updated TS-2954: -- Priority: Critical (was: Major) cache poisoning due to proxy.config.http.use_client_target_addr = 1 --- Key: TS-2954 URL: https://issues.apache.org/jira/browse/TS-2954 Project: Traffic Server Issue Type: Bug Components: Cache, DNS Reporter: Nikolai Gorchilov Priority: Critical Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid cache poisoning, while serving the fake response to the client. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolai Gorchilov updated TS-2954: -- Component/s: TProxy Security cache poisoning due to proxy.config.http.use_client_target_addr = 1 --- Key: TS-2954 URL: https://issues.apache.org/jira/browse/TS-2954 Project: Traffic Server Issue Type: Bug Components: Cache, DNS, Security, TProxy Reporter: Nikolai Gorchilov Priority: Critical Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid cache poisoning, while serving the fake response to the client. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolai Gorchilov updated TS-2954: -- Description: Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid possible cache poisoning, while still serving the origin response to the client. was: Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid possible cache poisoning, while still serving the original response to the client. cache poisoning due to proxy.config.http.use_client_target_addr = 1 --- Key: TS-2954 URL: https://issues.apache.org/jira/browse/TS-2954 Project: Traffic Server Issue Type: Bug Components: Cache, DNS, Security, TProxy Reporter: Nikolai Gorchilov Priority: Critical Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid possible cache poisoning, while still serving the origin response to the client. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolai Gorchilov updated TS-2954: -- Description: Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid possible cache poisoning, while still serving the original response to the client. was: Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid cache poisoning, while serving the fake response to the client. cache poisoning due to proxy.config.http.use_client_target_addr = 1 --- Key: TS-2954 URL: https://issues.apache.org/jira/browse/TS-2954 Project: Traffic Server Issue Type: Bug Components: Cache, DNS, Security, TProxy Reporter: Nikolai Gorchilov Priority: Critical Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid possible cache poisoning, while still serving the original response to the client. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1475) static analysis: clean up all clang and coverity reports
[ https://issues.apache.org/jira/browse/TS-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14071898#comment-14071898 ] ASF subversion and git services commented on TS-1475: - Commit 08c5d2b553f09f02c27e6f3f176bdfc94cbe4c1b in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=08c5d2b ] TS-1475 clang analyzer: errors on sizeof static analysis: clean up all clang and coverity reports Key: TS-1475 URL: https://issues.apache.org/jira/browse/TS-1475 Project: Traffic Server Issue Type: Bug Components: Cleanup Affects Versions: 3.3.0 Reporter: Zhao Yongming Fix For: sometime the new report is in https://ci.trafficserver.apache.org/files/clang-analyzer/latest/ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14071921#comment-14071921 ] Susan Hinrichs commented on TS-2954: Yes, the use_client_target_addr does expose a cache poisoning attack. The Host Header Forgery Detection would solve it in some (most?) cases. If the client and the trafficserver have access to the same DNS information then the Host Header Forgery Detection would solve the problem. The client could specify which specific server address the name should resolve to (important if the IP address is embedded elsewhere in the protocol). And trafficserver could verify this. The cache poisoner would be caught out. However, if you have a scenario where the client has access to different DNS information than the trafficserver, the Host Header Forgery Detection would not help. Perhaps the client is sitting with access to a corporate DNS server that the trafficserver does not have access to. Perhaps a tiered solution would work? By default set up proxy.config.http.use_client_target_addr to also employ Host Header Forgery Detection. Then add another option to disable the Host Header Forgery Detection in the small set of cases that have DNS mismatches between the client and the proxy. cache poisoning due to proxy.config.http.use_client_target_addr = 1 --- Key: TS-2954 URL: https://issues.apache.org/jira/browse/TS-2954 Project: Traffic Server Issue Type: Bug Components: Cache, DNS, Security, TProxy Reporter: Nikolai Gorchilov Priority: Critical Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid possible cache poisoning, while still serving the origin response to the client. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2955) support variable expansion in set-redirect operator for header_rewrite
Sudheer Vinukonda created TS-2955:
-
Summary: support variable expansion in set-redirect operator for
header_rewrite
Key: TS-2955
URL: https://issues.apache.org/jira/browse/TS-2955
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Sudheer Vinukonda
support variable expansion in set-redirect operator for header_rewrite to be
able to dynamically substitute variables in the Location header (currently,
only %{PATH} is supported).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2955) support variable expansion in set-redirect operator for header_rewrite
[
https://issues.apache.org/jira/browse/TS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2955:
--
Attachment: TS-2955.diff
support variable expansion in set-redirect operator for header_rewrite
--
Key: TS-2955
URL: https://issues.apache.org/jira/browse/TS-2955
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Sudheer Vinukonda
Attachments: TS-2955.diff
support variable expansion in set-redirect operator for header_rewrite to be
able to dynamically substitute variables in the Location header (currently,
only %{PATH} is supported).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2955) support variable expansion in set-redirect operator for header_rewrite
[
https://issues.apache.org/jira/browse/TS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14072466#comment-14072466
]
Scott Beardsley commented on TS-2955:
-
I specifically need:
PATH
QUERY_STRING
at the minimum.
Nice to have would be the other aspects of the URL like:
SCHEME
USER/PASSWORD
PORT
DOMAIN/HOST
One other comment about the proposed format... There already is variable
expansion[1] for add-header, perhaps we should stick to the same syntax for
this too?
[1]
http://trafficserver.readthedocs.org/en/latest/reference/plugins/header_rewrite.en.html#variable-expansion
support variable expansion in set-redirect operator for header_rewrite
--
Key: TS-2955
URL: https://issues.apache.org/jira/browse/TS-2955
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Sudheer Vinukonda
Attachments: TS-2955.diff
support variable expansion in set-redirect operator for header_rewrite to be
able to dynamically substitute variables in the Location header (currently,
only %{PATH} is supported).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2955) support variable expansion in set-redirect operator for header_rewrite
[
https://issues.apache.org/jira/browse/TS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14072488#comment-14072488
]
Sudheer Vinukonda commented on TS-2955:
---
[~sc0ttbeardsley] - PATH and QUERY_STRING are already supported using %{PATH}
and [QSA].
Below is an example that works:
set-redirect 301 https://host.xyz.com/%{PATH} [QSA]
I've added the variable expansion using % syntax to support other variables
(e.g %cquup, %chi etc).
support variable expansion in set-redirect operator for header_rewrite
--
Key: TS-2955
URL: https://issues.apache.org/jira/browse/TS-2955
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Sudheer Vinukonda
Attachments: TS-2955.diff
support variable expansion in set-redirect operator for header_rewrite to be
able to dynamically substitute variables in the Location header (currently,
only %{PATH} is supported).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2955) support variable expansion in set-redirect operator for header_rewrite
[
https://issues.apache.org/jira/browse/TS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14072488#comment-14072488
]
Sudheer Vinukonda edited comment on TS-2955 at 7/23/14 10:45 PM:
-
[~sc0ttbeardsley] - PATH and QUERY_STRING are already supported for
set-redirect using %{PATH} and [QSA].
Below is an example that works:
set-redirect 301 https://host.xyz.com/%{PATH} [QSA]
I've added the variable expansion using % syntax to support other variables
(e.g %cquup, %chi etc).
was (Author: sudheerv):
[~sc0ttbeardsley] - PATH and QUERY_STRING are already supported using %{PATH}
and [QSA].
Below is an example that works:
set-redirect 301 https://host.xyz.com/%{PATH} [QSA]
I've added the variable expansion using % syntax to support other variables
(e.g %cquup, %chi etc).
support variable expansion in set-redirect operator for header_rewrite
--
Key: TS-2955
URL: https://issues.apache.org/jira/browse/TS-2955
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Sudheer Vinukonda
Attachments: TS-2955.diff
support variable expansion in set-redirect operator for header_rewrite to be
able to dynamically substitute variables in the Location header (currently,
only %{PATH} is supported).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2955) support variable expansion in set-redirect operator for header_rewrite
[
https://issues.apache.org/jira/browse/TS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2955:
--
Fix Version/s: 5.1.0
support variable expansion in set-redirect operator for header_rewrite
--
Key: TS-2955
URL: https://issues.apache.org/jira/browse/TS-2955
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Sudheer Vinukonda
Labels: review
Fix For: 5.1.0
Attachments: TS-2955.diff
support variable expansion in set-redirect operator for header_rewrite to be
able to dynamically substitute variables in the Location header (currently,
only %{PATH} is supported).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2955) support variable expansion in set-redirect operator for header_rewrite
[
https://issues.apache.org/jira/browse/TS-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2955:
--
Labels: review (was: )
support variable expansion in set-redirect operator for header_rewrite
--
Key: TS-2955
URL: https://issues.apache.org/jira/browse/TS-2955
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Sudheer Vinukonda
Labels: review
Fix For: 5.1.0
Attachments: TS-2955.diff
support variable expansion in set-redirect operator for header_rewrite to be
able to dynamically substitute variables in the Location header (currently,
only %{PATH} is supported).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2953) GET Host header in reverse proxy setup
[
https://issues.apache.org/jira/browse/TS-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14072715#comment-14072715
]
portl4t commented on TS-2953:
-
You can try to get the url with TSHttpTxnEffectiveUrlStringGet(...) first.
GET Host header in reverse proxy setup
--
Key: TS-2953
URL: https://issues.apache.org/jira/browse/TS-2953
Project: Traffic Server
Issue Type: Bug
Components: Core, CPP API, Logging
Affects Versions: 4.2.1
Reporter: Vasile Bogdan Raica
Labels: API
Hello, been trying this for 3 days, I think this is a bug. See bellow code,
this has been tested on TS_HTTP_PRE_REMAP_HOOK and
TS_HTTP_READ_REQUEST_HDR_HOOK. Also the example for blacklist, which uses the
same thing, also fails.
Same goes with getting the URL string, it will remove the hostname and leave
the requested part, eg.
http:///somefile.php
(there are 3 slashes there).
I've been using ATS for about 3 days (yes short time) and trying to make a
plugin for it and I can't seem to get what I want ... I may be missing
something, and if so, I apologize for taking your time to read this and if
possible, kindly show me the right way to do this if possible.
static void
handle_request(TSHttpTxn txnp, TSCont contp) {
TSMBuffer bufp; // TSMBuffer
TSMLoc hdr_loc; // TSMLoc offset
TSMLoc url_loc; // TSMLoc locp
const char *host;
int host_length;
// getting client request
errorCode = TSHttpTxnClientReqGet (txnp, bufp, hdr_loc);
if (errorCode != TS_SUCCESS) {
TSError (couldn't retrieve client request header\n);
goto done;
} else {
TSTextLogObjectWrite(logFile, Reading client request...);
}
// getting client requested url
errorCode = TSHttpHdrUrlGet (bufp, hdr_loc, url_loc);
if (errorCode != TS_SUCCESS) {
TSError (couldn't retrieve request url\n);
TSHandleMLocRelease (bufp, TS_NULL_MLOC, hdr_loc);
goto done;
} else {
TSTextLogObjectWrite(logFile, Reading url_loc request...);
}
// getting host
host = TSUrlHostGet (bufp, url_loc, host_length);
TSTextLogObjectWrite(logFile, Getting host header... %s, host);
if (!host) {
TSError (couldn't retrieve request host header \n);
TSHandleMLocRelease (bufp, hdr_loc, url_loc);
TSHandleMLocRelease (bufp, TS_NULL_MLOC, hdr_loc);
goto done;
} else {
TSTextLogObjectWrite(logFile, Getting host header... %s, host);
}
done:
TSTextLogObjectWrite(logFile, Allowing http event to continue ...);
TSHttpTxnReenable(txnp, TS_EVENT_HTTP_CONTINUE);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2953) GET Host header in reverse proxy setup
[
https://issues.apache.org/jira/browse/TS-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14072741#comment-14072741
]
Vasile Bogdan Raica commented on TS-2953:
-
Hey, thanks for replying. Unfortunately not sure what you mean, as
TSHttpTxnEffectiveUrlStringGet() is not even in the docs ...
GET Host header in reverse proxy setup
--
Key: TS-2953
URL: https://issues.apache.org/jira/browse/TS-2953
Project: Traffic Server
Issue Type: Bug
Components: Core, CPP API, Logging
Affects Versions: 4.2.1
Reporter: Vasile Bogdan Raica
Labels: API
Hello, been trying this for 3 days, I think this is a bug. See bellow code,
this has been tested on TS_HTTP_PRE_REMAP_HOOK and
TS_HTTP_READ_REQUEST_HDR_HOOK. Also the example for blacklist, which uses the
same thing, also fails.
Same goes with getting the URL string, it will remove the hostname and leave
the requested part, eg.
http:///somefile.php
(there are 3 slashes there).
I've been using ATS for about 3 days (yes short time) and trying to make a
plugin for it and I can't seem to get what I want ... I may be missing
something, and if so, I apologize for taking your time to read this and if
possible, kindly show me the right way to do this if possible.
static void
handle_request(TSHttpTxn txnp, TSCont contp) {
TSMBuffer bufp; // TSMBuffer
TSMLoc hdr_loc; // TSMLoc offset
TSMLoc url_loc; // TSMLoc locp
const char *host;
int host_length;
// getting client request
errorCode = TSHttpTxnClientReqGet (txnp, bufp, hdr_loc);
if (errorCode != TS_SUCCESS) {
TSError (couldn't retrieve client request header\n);
goto done;
} else {
TSTextLogObjectWrite(logFile, Reading client request...);
}
// getting client requested url
errorCode = TSHttpHdrUrlGet (bufp, hdr_loc, url_loc);
if (errorCode != TS_SUCCESS) {
TSError (couldn't retrieve request url\n);
TSHandleMLocRelease (bufp, TS_NULL_MLOC, hdr_loc);
goto done;
} else {
TSTextLogObjectWrite(logFile, Reading url_loc request...);
}
// getting host
host = TSUrlHostGet (bufp, url_loc, host_length);
TSTextLogObjectWrite(logFile, Getting host header... %s, host);
if (!host) {
TSError (couldn't retrieve request host header \n);
TSHandleMLocRelease (bufp, hdr_loc, url_loc);
TSHandleMLocRelease (bufp, TS_NULL_MLOC, hdr_loc);
goto done;
} else {
TSTextLogObjectWrite(logFile, Getting host header... %s, host);
}
done:
TSTextLogObjectWrite(logFile, Allowing http event to continue ...);
TSHttpTxnReenable(txnp, TS_EVENT_HTTP_CONTINUE);
}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
