ProxyPass v10/v11 modifications - how to share?

I've just started using the ProxyPass v10/v11 iRule to move a number of Apache mod_proxy reverse proxies to our F5 HA pair. The first site moved was a simple HTTP clientside to HTTP serverside with no payload rewriting and it worked perfectly as documented. Then I started to see things that could be improved and a few things that didn't work and could be fixed.

Localised Options

The static::ProxyPassDebug and static::RewriteResponsePayload are inconvenient when the iRule is used by multiple virtual servers, so I've localised these for each virtual server in a new Data Group "ProxyPassOptionsVIRTUAL".

Protocol Rewriting

We offload SSL to some of our proxies so I found the request header and referer rewriting wasn't rewriting the protocol, resulting in the browser getting connection errors at least, I think, unless the virtual server accepts both HTTP and HTTPS in which case the iRule appears to trap the unchanged protocol in the new request and rewrites and redirects it back to itself. I have fixed this by inferring the serverside protocol for each pool from the ProxyPassSSLProfile information if it exists. There are a couple of assumptions/requirements supporting this method: 1. If any pool, default or alternative, requires SSL it must have a server profile entry in this data group. 2. The clientside protocol is detected via the CLIENTSSL_HANDSHAKE event.

Response Payload Protocol Rewriting

Payload rewriting doesn't rewrite the protocol. I have fixed this also following from previous item.

Response Payload Rewriting Generally

I think payload rewriting is incomplete if it only rewrites matching the current request URL components. That is, currently for a request rewrite e.g. "http://www.company.com/some/path" to "", the response payload will reverse only this URL. If the payload includes other absolute URLs e.g. "", this will be missed. So the iRule needs to be modified to rewrite just the "protocol://host_serverside" part for all URLs starting with that string, but it also needs to rewrite any path components that start with any path component in "ProxyPassVIRTUAL" that match the serverside host. For example, given the following "ProxyPathVIRTUAL":

"www.company.com/some/path" := "backend.internal/other/path"
"www.company.com/some/other/path" := "backend.internal/yet/another/path"

Given a request "http://www.company.com/some/path", all of the following rewrites need to occur if found in the response payload:

"http://backend.internal/other/path" -> "http://www.company.com/some/path"
"http://backend.internal/yet/another/path" -> "http://www.company.com/some/other/path"
"http://backend.internal/unchanged/path" -> "http://www.company.com/unchanged/path"
"/other/path" -> "/some/path"
"/yet/another/path" -> "/some/other/path"

URL rewriting and Case (In)Sensitivity

The original iRule assumes case sensitivity, which may be valid but is impractical. Unfortunately, we have a backend application running on Windows and the developers were arbitrary about case, hence an inbound request in lowercase will go through ok but response headers and payloads may contain the URL in uppercase.

Apache mod_proxy appears, from our experience, to handle this somehow, I assume by checking each response URL against all paths listed for proxying. Our Apache reverse proxy lists each path as lower and upper case and we have not had a problem. This is the same problem as "Response Payload Rewriting Generally" applied to header rewriting.

Current thinking is to add an option "ProxyPassURLDownCasing" to invoke down casing of all URL path elements before checking and rewriting. The option needs to be settable per pool, so the option value would probably be a list of pools.

Code Sharing

I haven't implemented the latter two items yet but I'm happy to provide the modified iRule code once I have if someone can tell me how I can upload it. I don't have any dev points to upload it directly and I tried posting the first three mods to this iRules forum but exceeded the word count and was rejected.

Thanks.