Nginx Module Code error_page directive problems

I am leveraging the ModSecurity WAF to help block tx's deemed dangerous on NGINX: https://github.com/SpiderLabs/ModSecurity https://github.com/SpiderLabs/ModSecurity-nginx

My issue can be found here: https://github.com/SpiderLabs/ModSecurity-nginx/issues/182

The TLDR of my problem is the nginx error_page directive resets the HTTP Request Method Header sent by the originating client during its redirect to GET. This causes false positive logs with the WAF to report client sent an HTTP Body with GET etc. when they really sent a POST and NGINX hits the error_page redirect due to some case with the upstream timing out on a reverse proxy call.

To fix this I need to hack in or PR something to this file section seemingly: https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/src/ngx_http_modsecurity_rewrite.c#L145

With the goal of something like this in sudo code:

//SAFE to trust this value as its the originating client HTTP REQUEST Method HEADER when not error_page
if(!r->error_page){
   const char *n_method = ngx_str_to_char(r->method_name, r->pool);
  //HOW to add a transaction persistent context value here to store STORED_CTX_HTTP_REQUEST_METHOD_HEADER_VALUE???
}
else {  //IF ERROR_PAGE, then we need to grab the original stored CTX request http method header value.
  const char *n_method = ngx_str_to_char(STORED_CTX_HTTP_REQUEST_METHOD_HEADER_VALUE); 
}

And it is here that I have been unable to solve the above sudo code. How does one create a tx context safe variable here that can persist across the phases and internal error_page redirect to store the original client http method header?

I landed on these NGINX page guides but so far no dice really seeing anything cutting into what I want: https://www.evanmiller.org/nginx-modules-guide.html

Looking for any NGINX / C guru's that understand the issue and might be able to turn my sudo code into something I can test in my sandbox environment.

Note I don't have the luxury of doing away with my NGINX error_page directive calls. So I do need a solution to the above sudo code I believe.

Thanks!

The fix I ended up going with can be seen here: https://github.com/SpiderLabs/ModSecurity-nginx/pull/204

There is no reason to re-process the clients requests in the earliest phases. This was the simplest approach. I just needed to take a high level step back and consider what was occurring here for the most elegant solution.