Your node server lies about its Content-Length.
That's the #1 reason for your issues, lack of truth about the
Content-Length.
When you under-send (Content-Length longer then actual response body
content), you get the java.io.EOFException: EOF reached while reading from
your initial message.
When
You're server is reporting the wrong Content-Length.
"HeadingSome Text" is 59
characters
But the server said "Content-Length: 58"
Also, "Connection: keep-alive" is a HTTP/1.0 concept only, but is being
reported on your HTTP/1.1 request/response improperly.
On Mon, May 14, 2018 at 7:20 PM, Simo
On Wed, Jun 22, 2016 at 5:39 AM, Pavel Rappo wrote:
> *. Please notice the difference between range of status codes accepted in
> `sendClose` and passed to `onClose`.
> So basically WebSocket will allow to receive status codes up to 65535
> (inclusive), but will not allow to send them if they are
Ping and Pong can interleave between frames (if a large message is being
broken up into frames that is).
Ping and Pong goto the head of the frame queue (post-extension processing)
in a manner of speaking.
Close should occur after the actively being sent message (aka once a
fin==true is encountere
I'm done with the UTF8 topic, you seem to have it in hand.
If you feel the existing facilities can handle it, go for it.
Just don't forget to test your impl on Autobahn Testsuite.
On Tue, Oct 20, 2015 at 3:06 PM, Pavel Rappo wrote:
> Hi Joakim,
>
> > On 20 Oct 2015, at
. For each TEXT message, there's 2 data copies (ByteBuffer ->
HeapCharBuffer -> String) for it to be practical to use in many 3rd party
libs (eg JSON parsing). For large messages, this can get expensive.
On Tue, Oct 20, 2015 at 5:57 AM, Pavel Rappo wrote:
> Hi Joakim,
>
>
hortBuffer.
On Tue, Oct 20, 2015 at 1:39 AM, Peter Levart
wrote:
>
>
> On 10/18/2015 12:08 AM, Pavel Rappo wrote:
>
>> Hi Joakim,
>>
>> On 17 Oct 2015, at 22:42, Joakim Erdfelt
>>> wrote:
>>>
>>> You are required, per the RFC6455 spec,
On Sat, Oct 17, 2015 at 11:56 AM, Pavel Rappo
wrote:
>
> >> * WebSocket.Builder no longer accepts HttpRequest.Builder; only
> HttpClient
> >> * One Listener instead of many onXXX handlers
> >
> > I tried to write a few examples with this API, and it's a bit cumbersome
> to use.
> > Below my fee
On Fri, Oct 9, 2015 at 8:07 AM, Paul Sandoz wrote:
> Hi Pavel, Simone,
>
> One way to make progress is to get the basic shape of the API agreed on
> without flow/resource management features. That probably represented the
> simplest form. I think we are very close to that.
>
> Then lets iterate f
Decided to take a stab at a list of "requirements"...
What do people want from a WebSocket client?
First, the baseline requirements:
(If you don't provide 100% of this list you have a inadequate
implementation):
Initiate a connection
- simple connect (URI)
- advanced connect (HttpClien
API layer in stone?
or based on some sort of user/developer feedback?
or encouraged based on guidelines for java, the JDK, or classlib?
can alternate APIs be proposed still?
- Joakim Erdfelt
Eclipse/Jetty WebSocket Implementor
On Mon, Aug 31, 2015 at 7:30 AM, Pavel Rappo wrote:
> Hi
11 matches
Mail list logo
