[
https://issues.apache.org/jira/browse/TS-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945470#comment-13945470
]
Ron Barber commented on TS-2656:
--------------------------------
Great points. After talking to Bryan, consider this instead:
ATS currently sets the server connection scheme (sm->t_state.scheme) after
remapping has occurred based on the server URL. {sm->t_state.scheme} is
evaluated immediately prior to establishing a new server connection to
determine if {sslNetProcessor.connect_re} or {netProcessor.connect_re} should
be called to setup the connection. Plugin's that desire to modify the
connection scheme after remapping (such as in the TS_EVENT_HTTP_OS_DNS event)
have no method to do so.
Rather than getter/setter functions that manipulate the scheme, modify ATS to
determine the connection scheme (based on server URL) immediately prior to
connecting. Here is the patch (needs more testing to make sure it doesn't
cause harm):
{code}
diff --git a/proxy/http/HttpSM.cc b/proxy/http/HttpSM.cc
index b314bc9..df86490 100644
--- a/proxy/http/HttpSM.cc
+++ b/proxy/http/HttpSM.cc
@@ -4653,7 +4653,15 @@ HttpSM::do_http_server_open(bool raw)
}
}
- if (t_state.scheme == URL_WKSIDX_HTTPS) {
+ int scheme_to_use;
+ if(!t_state.is_websocket) {
+ // if not websocket, then get scheme from server request
+ scheme_to_use =
t_state.hdr_info.server_request.url_get()->scheme_get_wksidx();
+ } else {
+ // websockets set the scheme so use what was set
+ scheme_to_use = t_state.scheme;
+ }
+ if (scheme_to_use == URL_WKSIDX_HTTPS) {
DebugSM("http", "calling sslNetProcessor.connect_re");
connect_action_handle = sslNetProcessor.connect_re(this, // state
machine
&t_state.current.server->addr.sa, // addr + port
{code}
> Determine server connection scheme immedately before connecting.
> ----------------------------------------------------------------
>
> Key: TS-2656
> URL: https://issues.apache.org/jira/browse/TS-2656
> Project: Traffic Server
> Issue Type: Improvement
> Reporter: Ron Barber
> Attachments: TS-2656.patch
>
>
> ATS currently sets the server connection scheme (sm->t_state.scheme) after
> remapping has occurred based on the server URL. Plugin's that desire to
> modify the connection scheme after remapping (such as in the
> TS_EVENT_HTTP_OS_DNS event) have no method to do so. I propose adding the
> following getter/setter API functions:
> {code}
> /**
> Retrieves the server connection scheme for the specified
> transaction @a txnp. TSHttpTxnServerSchemeGet() places the length of
> the string in the length argument. If the length is NULL then no
> attempt is made to dereference it.
> @note This function is useful if the server connection scheme needs to
> retrieved post remapping.
> @param txnp The transaction whose connection scheme to be retrieved
> @param length length of the returned string.
> @return The connection scheme for the server connection, as a string,
> or NULL if not set.
> */
> tsapi const char* TSHttpTxnServerSchemeGet(TSHttpTxn txnp, int *length);
> /** Set the connection scheme to the server (http or https) for the
> specified transaction @a txnp to the string value. If length is -1
> then TSHttpTxnServerSchemeSet() assumes that value is null-terminated.
> Otherwise, the length of the string value is taken to be length.
> @note This function is useful if the server connection scheme needs to
> change post remapping.
> @param txnp The transaction whose connection scheme to be set
> @param value value to set the scheme to.
> @param length string stored in value.
> @return @c TS_SUCCESS if scheme is recognized, else @c TS_ERROR
> */
> tsapi TSReturnCode TSHttpTxnServerSchemeSet(TSHttpTxn txnp,
> const char* value,
> int length);
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
