So, it's impossible to implement BOSH on HTTP/1.1, right? What about HTTP pipelining, is it possible to have it?
https://tools.ietf.org/html/rfc2616 8.1.2.2 Pipelining A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received. Clients which assume persistent connections and pipeline immediately after connection establishment SHOULD be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it MUST NOT pipeline before it knows the connection is persistent. Clients MUST also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request. вт, 23 июл. 2019 г. в 19:08, Joakim Erdfelt <[email protected]>: > Sounds like you want to use either Bayeux (like cometd), or WebSocket > (like Jetty websocket). > > HTTP is a request/response exchange. > For HTTP/1.1 - its sequential on the connection. you can't delay a > response, as the commit + complete of that response is the trigger for the > next request processing on HTTP/1.1. > For HTTP/2 it's 100% concurrent, requests on different channels, etc.. > For HTTP/3 it's also 100% concurrent, requests on different channels too. > etc.. > > The BOSH spec you linked is rather old now. Referencing outdated (years > ago now) HTTP specs. > For example, the updated HTTP specs make some of the assumptions in BOSH > 2. Requirements and 3. Architectural Assumptions no longer valid. > > Joakim Erdfelt / [email protected] > > > On Tue, Jul 23, 2019 at 10:57 AM Sergey O <[email protected]> wrote: > >> Hello, >> >> The response on the first request should be sent right after the >> second request is received. >> >> Best regards, >> Sergey >> >> вт, 23 июл. 2019 г. в 18:50, Joakim Erdfelt <[email protected]>: >> >>> "we need ability to sequentially (not concurrently) process a second >>> HTTP POST request" >>> >>> The first part of this sentence says sequentially (not concurrently), >>> but the description in the second half describes concurrent behavior. >>> So which is it? >>> >>> Joakim Erdfelt / [email protected] >>> >>> >>> On Tue, Jul 23, 2019 at 10:47 AM Joakim Erdfelt <[email protected]> >>> wrote: >>> >>>> Standard HTTP/1.1 has persistent connections. >>>> >>>> The requests are processed in the order they are received. >>>> Sequentially. >>>> The responses are returned in the order they are processed. Also >>>> Sequentially. >>>> >>>> Joakim Erdfelt / [email protected] >>>> >>>> >>>> On Tue, Jul 23, 2019 at 10:45 AM Sergey O <[email protected]> wrote: >>>> >>>>> Hello, >>>>> >>>>> Is it possible to implement server which supports some kind of the >>>>> BOSH protocol (http://xmpp.org/extensions/xep-0124.html) with jetty? >>>>> Particularly, we need ability to sequentially (not concurrently) >>>>> process a second HTTP POST request before response on a first one is sent. >>>>> Both requests should use the same persistent connection. >>>>> If it is not possible to start the second request processing prior to >>>>> response on the first one is sent, is it possible to receive notification >>>>> about the second request availability? >>>>> >>>>> Best regards, >>>>> Sergey >>>>> _______________________________________________ >>>>> jetty-users mailing list >>>>> [email protected] >>>>> To change your delivery options, retrieve your password, or >>>>> unsubscribe from this list, visit >>>>> https://www.eclipse.org/mailman/listinfo/jetty-users >>>> >>>> _______________________________________________ >>> jetty-users mailing list >>> [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://www.eclipse.org/mailman/listinfo/jetty-users >> >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://www.eclipse.org/mailman/listinfo/jetty-users > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
