304 Responses should not contain a body

[tsemroc]

The proxy in my environment is sitting behind a load balancer. The load balancer rejects 304 responses containing a body. According to the HTTP specification 304's should never contain a body:
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5

The context.Response.OutputStream.Write(bytes, 0, bytes.Length); writes bytes to the body of the response that causes to the response to be blocked by our load balancer.

I made a modification to the code in my instance in catch block of the forwardToServer try and made it so no outputStream is written in a 304.
``

    System.Net.WebResponse serverResponse = null;
    try {
        serverResponse = forwardToServer(context.Request, addTokenToUri(requestUri, token, tokenParamName), postBody, credentials);
    } catch (System.Net.WebException webExc) {

        string errorMsg = webExc.Message + " " + uri;
        log(TraceLevel.Error, errorMsg);

        if (webExc.Response != null)
        {
            copyResponseHeaders(webExc.Response as System.Net.HttpWebResponse, context.Response);

            using (Stream responseStream = webExc.Response.GetResponseStream())
            {
                byte[] bytes = new byte[32768];
                int bytesRead = 0;

                while ((bytesRead = responseStream.Read(bytes, 0, bytes.Length)) > 0)
                {
                    responseStream.Write(bytes, 0, bytesRead);
                }


                context.Response.StatusCode = (int)(webExc.Response as System.Net.HttpWebResponse).StatusCode;
                
                // ********************
                // Code to ensure 304 responses do not contain a body
                // ********************
                if (context.Response.StatusCode != 304)
                {
                    context.Response.OutputStream.Write(bytes, 0, bytes.Length);
                }
              
            }
        }

[fspataro-zz]

I'm running into a similar problem with 304s that only occurs in our PRD/TEST environment that's behind a load balancer/firewall. It's completely crippled our app functionality that uses the proxy for secure services. So far I've had no luck identifying the issue but it's felt like something along these lines... I'll test that code.

My GeoNet write-up is here: https://community.esri.com/message/792269-requests-via-the-proxy-fail-after-first-attempt-something-with-cache-control

[fspataro-zz]

Confirming this is the issue we are experiencing and fix supplied by @tsemroc corrects the issue. Our firewall/load balancer is an F5 product. I suspect many others have this issue.

[sardeenz]

Thank goodness we found this. We also have f5 and were pulling our hair out trying to get authentication to work. This appears to have fixed our issue.

[bsvensson]

@tsemroc - thanks for providing a code snippet that helps people!

Would you like to create a pull request with your changes? (If not, we can attempt to do it based on your code above).

[bsvensson]

Thank you @sardeenz for submitting it as a PR. The PR has been merged.

[green3g]

We're still running into tons of issues with this error. Seems the fix did not resolve the issue. It appears random and when it happens entire basemaps appear to crash in the application.

2019-01-23 08:26:59 The remote server returned an error: (304) Not Modified.