☰

Apache2 mod_proxy umschließt den HTTP-Header, anstatt ihn weiterzuleiten

tag-icon • tag-icon mod-proxy apache2 oracle-application-server
Apache2 mod_proxy umschließt den HTTP-Header, anstatt ihn weiterzuleiten

Wenn ich über einen Apache-Proxy auf einen Oracle Apex-Server zugreife, erhalte ich sporadisch das folgende HTTP-Paket als Antwort vom 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

Ich weiß nicht, woher die 0 kommt. Es scheint jedoch, dass der Proxy die komplette HTTP-Antwort, die er von APEX erhält (einschließlich des HTTP-Headers), als HTTP-Body in ein anderes HTTP-Paket verpackt:

<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>

Stattdessen sollte der Proxy das HTTP-Paket einfach an den Client weiterleiten. So dass der Client das HTTP-Paket so empfängt, als käme es von APEX, ohne zu wissen, dass es vom Proxy weitergeleitet wurde. Dies funktioniert in 29 von 30 Fällen wie erwartet, manchmal verhält es sich jedoch wie oben beschrieben. Ist das ein Fehler im Proxy? Können Sie bitte einen möglichen Workaround vorschlagen?

Antwort1

Dies ist kein Umbruch, sondern liegt am transfer-encoding: chunkedHeader. Siehehttps://en.wikipedia.org/wiki/Chunked_transfer_encoding

Die 0 ist das Signal des letzten Blocks. Von der obigen Seite:

Jeder Block beginnt mit der Anzahl der Oktette der eingebetteten Daten, ausgedrückt als Hexadezimalzahl in ASCII, gefolgt von optionalen Parametern (Blockerweiterung) und einer abschließenden CRLF-Sequenz, gefolgt von den Blockdaten. Der Block wird durch CRLF abgeschlossen.

Und

Der abschließende Block ist ein normaler Block, mit der Ausnahme, dass seine Länge null ist. Ihm folgt der Trailer, der aus einer (möglicherweise leeren) Folge von Entity-Headerfeldern besteht. Normalerweise würden solche Headerfelder im Header der Nachricht gesendet. Es kann jedoch effizienter sein, sie nach der Verarbeitung der gesamten Nachrichtenentität zu bestimmen. In diesem Fall ist es sinnvoll, diese Header im Trailer zu senden.

Versuchen Sie es SetEnv proxy-nokeepalive 1in Ihrer Apache mod_proxy-Konfiguration. Oder versuchen Sie

SetEnv proxy-sendcl 1

SetEnv proxy-sendchunked 0

Sehenhttp://httpd.apache.org/docs/2.4/mod/mod_proxy.html#request-bodiesfür Erklärungen.

verwandte Informationen