http - trabajo - que responder cuando te preguntan que sabes hacer
Respuesta HTTP antes de la solicitud (7)
Mi pregunta puede sonar estúpida, pero solo quería estar seguro:
- ¿Es posible enviar una respuesta HTTP antes de tener la solicitud de ese recurso?
Digamos, por ejemplo, que tiene una página HTML index.html que solo muestra una imagen llamada img.jpg . Ahora, si su servidor sabe que un visitante solicitará el archivo HTML y luego la imagen jpg cada vez:
¿Sería posible que el servidor envíe la imagen justo después del archivo HTML para ahorrar tiempo?
Sé que HTTP es un protocolo síncrono, por lo que en teoría no debería funcionar, pero solo quería que alguien lo confirmara (o no).
Está buscando inserción de servidor : no está disponible en HTTP. Protocolos como SPDY lo tienen, pero no tienes suerte si estás restringido a HTTP.
No creo que sea posible mezclar .html e imagen en la misma respuesta HTTP. En cuanto al envío de datos de imagen ''inmediatamente'', inmediatamente después de la primera solicitud, existe un concepto de ''recursos estáticos'' que podría ser de ayuda (pero requerirá que el cliente cree un nuevo requerimiento para un recurso específico).
Hay un par de cosas interesantes mencionadas en el article .
No, no es posible.
La primera línea de la solicitud contiene el recurso solicitado, por lo que no sabría a qué responder a menos que primero examinara los bytes (al menos una línea) de la solicitud.
No. HTTP se define como un protocolo de solicitud / respuesta. Una solicitud: una respuesta. Cualquier otra cosa no es HTTP, es otra cosa, y tendría que especificarla adecuadamente e implementarla por completo en ambos extremos.
Obtendrá un mejor resultado al almacenar en caché los recursos de manera efectiva, es decir, establecer encabezados de caché adecuados y configurar su servidor web para el almacenamiento en caché. También puede alinear imágenes usando codificación base 64 , si eso es una preocupación específica.
También puede consultar las soluciones de javascript de larga duración .
Si alguien solicita /index.html y envía dos respuestas (una para /index.html y la otra para /img.jpg), ¿cómo sabe que el destinatario recibirá las dos respuestas y sabrá qué hacer con ellas antes de la segunda la solicitud entra?
El problema no es realmente con el envío. El problema es que el receptor posiblemente obtenga datos inesperados.
Otro problema es que le niega al cliente la capacidad de usar herramientas de caché HTTP como If-Modified-Since y If-None-Match (es decir, el cliente puede no querer que se envíe /img.jpg porque ya tiene un caché dupdo).
Dicho esto, puede aproximar los beneficios de servidor-empuje mediante el uso de técnicas Comet . Pero eso es mucho más complicado que simplemente anticipar las solicitudes HTTP entrantes.
Una publicación reciente de Jacques Mattheij , haciendo referencia a su propia pregunta, afirma que aunque HTTP se diseñó como un protocolo sincrónico, la implementación no lo fue. En la práctica, el navegador (que no especifica cuál) acepta las respuestas a las solicitudes que aún no se han enviado.
Por otro lado, si buscas algo menos hacky, puedes echar un vistazo a:
- técnicas de inserción que permiten al servidor enviar contenido al navegador. La implementación moderna que reemplaza a los "hacks" de larga duración / Comet son los websockets . Es posible que desee echar un vistazo a socket.io también.
- Alternativamente, es posible que desee echar un vistazo al enrutamiento del lado del cliente . Algunas implementaciones combinan esto con técnicas de almacenamiento en caché (como en derby.js , creo).