Apache ProxyRequest

Question

Eu tenho um servidor Apache em execução na porta 8888 no meu ambiente de desenvolvimento. Eu gostaria que meu servidor WebSocket usasse a mesma porta. (O motivo está no ambiente ao vivo, não é 8888 e queremos que todos os usuários possam usar o websocket para que a porta 80 seja a melhor).

Eu pensei que, se eu pudesse fazer proxy na chamada para o 8888 para o WebSocket interno que está hospedado na porta 12345, o soquete pode funcionar.

Até agora, habilitei

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

Eu adicionei ao meu httpd.conf:

<VirtualHost *:8888>
    ProxyRequests On
    ProxyPass ^serverWebSocket.php ws://localhost:12345/serverWebSocket.php
    ProxyPassReverse ^serverWebSocket.php ws://localhost:12345/serverWebSocket.php 
</VirtualHost>

O Javascript abre um soquete dessa maneira:

 socket = new WebSocket("ws://localhost:8888/serverWebSocket.php"); 

Eu sei o código Javascript e servidor PHP para websocket funciona porque se eu simplesmente colocar a porta 12345 diretamente ele funciona. Mas agora, eu quero usar a porta externa 8888.

O que estou perdendo?

    

Answer 1

Primeiramente: desative ProxyRequests! Esta diretiva é para criar um servidor proxy que pode receber solicitações para todos os sites na Internet; ele será encontrado e usado para coisas que você não quer que ele faça se exposto à rede.

De qualquer forma, mudar seu ProxyPass (e reversão correspondente) deve fazer o truque. Não há regex aqui e ele usa caminhos absolutos no contexto <VirtualHost> . Se você precisa de regex, você pode usar mod_rewrite, mas não parece que você faz.

ProxyPass /serverWebSocket.php http://localhost:12345/serverWebSocket.php
ProxyPassReverse /serverWebSocket.php http://localhost:12345/serverWebSocket.php

    

Answer 2

Acho que você vai querer usar o Apache 2.4 e usar seu módulo mod_proxy_wstunnel.

link

Eu até acho preferível que você tenha endpoint de API em um nome de host diferente (por exemplo, api.example.com versus www.example.com), o que significa que você pode separar seu tráfego de API do tráfego não-API, e usar infra-estrutura adequada para cada um. (Exemplo: ouvi recentemente que o público do Varnish lançou um produto como o verniz, mas para o gerenciamento de APIs --- e isso é tudo que eu sei disso atualmente).

Eu não ficaria confortável em ter o Apache (pelo menos o 2.2, que é o que eu uso) servindo um endpoint da API devido a preocupações com o C10K.