Major Description
The existing TS API TSHttpHdrVersionSet allows to set http version of an outgoing http request. However, this does only that (just update the version field in the request). It doesn't necessarily use the updated version to build the http request accordingly (for instance, if the http version of a 1.1 request is modified to 0.9 using this API, the request will still contain the Host header. It doesn't remove the Host header, based on the version). It would be desirable to have a TS API that can set the origin version and influence the building of the request accordingly. See also related jiras TS-3326 and TS-3327
Below is an example of such API:
diff --git a/proxy/InkAPI.cc b/proxy/InkAPI.cc index 1abdcbf..07809b2 100644 --- a/proxy/InkAPI.cc +++ b/proxy/InkAPI.cc @@ -5270,6 +5270,20 @@ TSHttpTxnServerAddrSet(TSHttpTxn txnp, struct sockaddr const* addr) } } +TSReturnCode +TSHttpTxnServerHttpVersionSet(TSHttpTxn txnp, int ver) +{ + sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS); + + HttpSM *sm = reinterpret_cast<HttpSM *>(txnp); + HTTPVersion version(ver); + if (version != HTTPVersion(0, 0)) { + sm->t_state.server_info.http_version = version; + return TS_SUCCESS; + } + return TS_ERROR; +} + void TSHttpTxnClientIncomingPortSet(TSHttpTxn txnp, int port) { diff --git a/proxy/api/ts/ts.h b/proxy/api/ts/ts.h index 4783b97..9a0e80c 100644 --- a/proxy/api/ts/ts.h +++ b/proxy/api/ts/ts.h @@ -1329,6 +1329,15 @@ extern "C" tsapi TSReturnCode TSHttpTxnServerAddrSet(TSHttpTxn txnp, struct sockaddr const* addr /**< Address for origin server. */ ); + /** Set the outgoing server http version. + + This must be invoked before the server request is sent. + + @return @c TS_SUCCESS if the outgoing server http version is valid, @c TS_ERROR otherwise. + */ + tsapi TSReturnCode TSHttpTxnServerHttpVersionSet(TSHttpTxn txnp, + int ver /**< http version for outgoing server request. */ + ); /** Get the next hop address. *
However, discussing this API on the IRC, zwoop pointed out the inconsistency/confusion this new API might bring in with the existing TS API TSHttpHdrVersionSet. Specifically, the resultant behavior of a plugin using both API is unpredictable depending on the hooks used. But, the need for such an API is still there, so opening this jira to track that requirement. The final solution may involve coming up with a single API that can do both what the existing API does and the requirement to build the Http request accordingly.