0

Accessing an oracle apex server via an apache proxy, I sporadically get the following HTTP Package as a response from the server:

Connection:Keep-Alive
Date:Fri, 20 Jan 2017 16:00:24 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.4.6 () PHP/5.4.16
Transfer-Encoding:chunked

0
HTTP/1.1 200 OK
Server: Oracle XML DB/Oracle Database
Content-Type: text/html; charset=utf-8
Content-Length: 33388

ACTUAL HTML PAGE FROM APEX

I don't know where the 0 comes from. Though it seems that the Proxy wraps the complete HTTP response it gets from APEX (including the HTTP header) as a HTTP body into another HTTP package:

<Apache HTTP PACKAGE>
    <Apache HTTP HEADER>
        Connection:Keep-Alive
        Date:Fri, 20 Jan 2017 16:00:24 GMT
        Keep-Alive:timeout=5, max=100
        Server:Apache/2.4.6 () PHP/5.4.16
        Transfer-Encoding:chunked

    </Apache HTTP HEADER>
    <Apache HTTP BODY>
        0
        <APEX HTTP PACKAGE>
                HTTP/1.1 200 OK
                Server: Oracle XML DB/Oracle Database
                Content-Type: text/html; charset=utf-8
                Content-Length: 33388

                ACTUAL HTML PAGE FROM APEX
        </APEX HTTP PACKAGE>
    </Apache HTTP BODY>
</Apache HTTP PACKAGE>

Instead, the proxy should simply forward the HTTP Package to the client. So that the client receives the HTTP Package as if it comes from APEX without being aware that it was forwarded by the Proxy. This works as expected 29 out of 30 times, but sometimes it behaves as described above. Is this a Bug in the Proxy? Could you please suggest a possible workaround?

phobic
  • 103
  • 1
  • 5

1 Answers1

0

This is not a wrapping, it is due to the transfer-encoding: chunked header. See https://en.wikipedia.org/wiki/Chunked_transfer_encoding

The 0 is the signal of the final chunk. From the above page:

Each chunk starts with the number of octets of the data it embeds expressed as a hexadecimal number in ASCII followed by optional parameters (chunk extension) and a terminating CRLF sequence, followed by the chunk data. The chunk is terminated by CRLF.

and

The terminating chunk is a regular chunk, with the exception that its length is zero. It is followed by the trailer, which consists of a (possibly empty) sequence of entity header fields. Normally, such header fields would be sent in the message's header; however, it may be more efficient to determine them after processing the entire message entity. In that case, it is useful to send those headers in the trailer.

Try SetEnv proxy-nokeepalive 1 in your Apache mod_proxy configuration. Or try

SetEnv proxy-sendcl 1

SetEnv proxy-sendchunked 0

See http://httpd.apache.org/docs/2.4/mod/mod_proxy.html#request-bodies for explanations.

Patrick Mevzek
  • 9,921
  • 7
  • 32
  • 43
  • Thanks for the clarification. But I still don't see why my browser page displays the signal for the final chunk. Or for that matter, why does it display any protocol internals that should stay hidden from the user? I expect the proxy to handle the communication transparently, even when using chunked encoding. Is there any mention that the proxy does not support using chunked encoding? I did switch to HTTP 1.0, to prevent chunked encoding, but I still see this as a problem with the proxy. – phobic Mar 24 '17 at 13:53
  • Have you tried the configuration I gave you, specifically the last SetEnv ? Are you using Apache mod_proxy or something else ? – Patrick Mevzek Mar 24 '17 at 20:46
  • Sorry for the confusion. Your workaround is solid. The problem does not occur with the suggested configuration. By "I still see this as a problem with the proxy" I meant that this configuration should not be necessary. The proxy should handle the requests transparently anyway. So why doesn't it? – phobic Mar 25 '17 at 21:47