lose the connection, but oops the next request was already sent and
it's now lost.
So the client cannot reuse that connection to send another request ever.
No other choice than to close it.
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free
t messed up.
In case you wonder, there are so many other ways to screw things up
that really, there is no other way than closing the connection :)
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
th
to use this mechanism for addressing
> issue described in JDK-8257080.
Is it hopefully going to be non-blocking?
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique
tImpl).
Can this be clarified?
I did not look much further if there are other inconsistencies, but a
more general review may be needed.
Thanks!
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability
throws (on Windows).
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
ication between lines 98-101 and 123-125.
The second set of lines lacks the charset parameter that the first set
of lines added, so there is a chance to factor those lines to a common
method.
I'm a JDK author and I can open a bug about this.
Thanks!
--
Simone Bordet
---
Finally, no matter
ly implement logics such as SameSite.
Currently the only option applications have is to _not_ use the JDK
classes (CookieManager & CookieStore) and do manually the parsing of
Set-Cookie, the storage of cookies, and their retrieval - it's not
optimal (code duplication, introducing bugs, different i
265 and 6265bis.
Thanks!
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
se moment, the bandwidth*delay product, dynamic adjustments of
the HTTP/2 flow control window, etc.).
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
ow control,
with the same effects on performance.
Opening few connections (many many less that you would with HTTP/1.1)
showed to be a good compromise between resource utilization and
performance (and outperforms HTTP/1.1).
--
Simone Bordet
---
Finally, no matter how good the architecture and desi
Hi,
On Thu, Aug 2, 2018 at 10:44 AM Michael McMahon
wrote:
> On 31/07/2018, 22:07, Simone Bordet wrote:
> ..
> > Finally, I would consider TLS handshake time as part of the request
> > data: the cost will be paid by the first request and capped by "total"
> >
;total" timeout elapses, exchange can be: queued, sending or
receiving; in all cases fail the exchange.
5. exchange completes in time, cancel "total" timeout.
Thanks!
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
urprised at how many bad server exist out there, and
how creative people can be in using HTTP.
I would not base the behavior of the JDK HttpClient on false
assumptions, especialy that HTTP responses must finish _after_ HTTP
requests.
It has never been the case since the inception of HTTP.
Thanks
2 minutes), a request will fail in 5 seconds
if HttpClient fails to open a connection to the origin server, and
fail in 2 minutes if it takes too much.
Finally, I would consider TLS handshake time as part of the request
data: the cost will be paid by the first request and capped by "total"
timeout (not connectTimeout).
With TLS 1.3 optimizations, it may be just few TLS bytes before the
encrypted request bytes.
Thanks!
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
Resend with proper subject, doh.
-- Forwarded message --
From: Simone Bordet
Date: Wed, Jun 6, 2018 at 10:29 AM
Subject:
To: "net-dev@openjdk.java.net >> OpenJDK Network Dev list"
Hi,
we have stumbled upon the error below on Windows.
We suspect this is happen
)
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
Processor/Subscriber
implementation should just extend a ReactiveStream TCK class
overriding a few methods, for example:
https://github.com/jetty-project/jetty-reactive-httpclient/blob/master/src/test/java/org/eclipse/jetty/reactive/client/internal/QueuedSinglePublisherTCKTest.java
The ReactiveStreams TCK doe
implement.
> I accept that a carrier would be a more friendly for possible evolution,
> maybe:
>
> BodyHandlerInfo {
> int statusCode() {... }
> HttpHeaders responseHeaders { ... }
> }
>
> Does this satisfy your concern?
Yes.
This class could already hold the HTT
and
almost none to handle Subscribers: Publishers are exposed, Subscribers
hidden.
I don't see any confusion.
Thanks !
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementati
an IntelliJ warning telling me that I should not do
that!), will cause confusion and be potential source of bugs - we all
know non-blocking/async programming is hard.
Thanks !
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with opti
leFuture) should have been taken for
HTTP with even more importance, given how more popular is HTTP over
WebSocket.
I would like this revision to be taken into consideration, offering an
efficient low-level API for HTTP as well.
Thanks !
--
Simone Bordet
---
Finally, no matter how good the arc
the WebSocket
frames, I know what to do", sticking to least surprise.
One last orthogonal comment about usage of the Flow APIs in the new HTTP client.
As far as I know the Flow APIs are only used for request and response
content, not the for HTTP protocol lifecycle.
HTTP requests/response
s that the implementation must reassemble on her
behalf, no ?
So it will *always* be the case that zero copy is possible, right ?
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the impleme
x27;t see why not ?
Read from network, parse header bytes, slice the buffer, call the
listener. Zero copy.
Can you expand ?
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation t
le
with JDK 8 there may have been hidden copies to provide a full
ByteBuffer.
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschit
Hi,
On Tue, Feb 20, 2018 at 10:22 AM, Alan Bateman wrote:
>
>
> On 20/02/2018 08:14, Simone Bordet wrote:
>>
>> :
>> Where would be a good list to start discussing ByteBuffer to
>> [Input|Output]Stream bridging ?
>>
> Are you looking for this for perfor
Alan,
On Tue, Feb 20, 2018 at 8:50 AM, Alan Bateman wrote:
> On 19/02/2018 20:19, Simone Bordet wrote:
>>
>> :
>> Now, ByteBufferInputStream is not present in the JDK, and if you want
>> to complain you are in good (and conspicuous) company, as the JDK
>> en
bridge between ByteBuffer and [Input|Output]Stream
will solve a million cases.
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
- I have not written it myself and for this kind
of things often the details are hidden until a serious implementation
effort is attempted.
Thanks !
--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
erfering with their throughput, with proxy applications that have
different speeds on the 2 sides they proxy, and so on.
Here I am seriously advocating to the net-dev JDK group to provide an
efficient solution, or at least start a discussion where appropriate,
for ByteBuffer to [Input|Output]
ly
when connecting to multiple domains.
I would suggest smaller values.
Our experience is that even in fast network (not localhost) 16 MiB
session windows will hit TCP congestion control before stalling HTTP/2
flow control.
--
Simone Bordet
---
Finally, no matter how good the architecture and
lementation detail”. Does this sound like a
> good idea ? If so I would be happy to come up with a patch against openjdk.
>
I wholeheartedly support this.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-fr
a classic getter method, and the uppercase allows people to
quickly identify that is different.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementatio
essage.
It's not a programming error, it's just the result of events happening
at the same time.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
eanup());
} catch (Throwable x) {
// Uh, no idea if the implementation actually closed !
// Let's *hope* this one goes fine :/
ws.sendClose(1000, "short").handle((ws, th) -> cleanup());
}
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
Hi,
On Thu, Jun 23, 2016 at 7:00 PM, Pavel Rappo wrote:
> But I still think we probably more safe assuming the intersection of our
> understandings, rather than a union :-)
Chris and I agreed, so now you're minority :)
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no
m Pavel's, we're
just discussing different interpretations here and try to come out
with a good/common one.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the i
considers the WebSocket connection closed and MUST close the
underlying TCP connection."
Which tells that an endPoint closes the TCP connection when it is
fully closed (2 halves).
So, if you *have* to continue reading from the network to read the
reply close frame, what do
e).
And the disagreement is that TCP can send an unlimited amount of data
in half closed state, while WebSocket *seems* to hint that it *may*
send a *non specified* amount of fragments ?
:)
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design
om onClose(), and the implementation will send the reply close frame
(if not already sent by the application).
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
> programming
> model, not using CF's will be most common, but it doesn’t get in the way of a
> more sophisticated advanced usage.
However, you still want to use the CFs for exception reporting.
BTW, this suggestion was ruled out by Pavel when I suggested it.
Not sure who overrules
Hi,
On Tue, Jun 14, 2016 at 2:36 PM, Simone Bordet wrote:
> That is again a semantic problem, but I think this one is simple: the
> implementation cannot guarantee that one API call correspond to one
> frame.
> There are, for example, fragmentation extensions that
> fragment/re
Hi,
On Tue, Jun 14, 2016 at 1:26 PM, Pavel Rappo wrote:
>
>> On 13 Jun 2016, at 12:14, Simone Bordet wrote:
>>
>>> Should the application be in charge of chopping outgoing messages in chunks
>>> in
>>> order to provide better responsiveness when
Hi,
On Mon, Jun 13, 2016 at 3:40 PM, Pavel Rappo wrote:
>
>> On 13 Jun 2016, at 12:14, Simone Bordet wrote:
>>
>> Close should definitely *not* "jump ahead of the queue", it should be
>> sent after queued stuff has been sent.
>
> Why is that?
Becau
emantic for sendX() is "at most one outstanding write" I
would not consider a ping an outstanding write: it can be performed at
any time.
> 2. Does "sendPing" have to wait until the CF returned by the previous sendPing
> has completed?
I'd say no.
--
Simone Bordet
htt
e are additional burdens on applications, but at
least it's clear to an application what it should do.
If you choose the last, then an application has to assume the least,
and it has to write code with only one outstanding write.
At that point you (as implementer) have the burden of putting
x is the same as above, write the application thinking this
properly, but now there is a double work: the application queueing,
and the implementation queueing.
Alternatively, you can make this semantic explicitly configurable in
the Builder ?
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
the idea was that you always want *at most* one outstanding write.
Multiple writes should be chained via CS.
Concurrent writes are handled by applications.
Are you saying that with this change, you allow infinite buffering ?
To be clear, do you want to allow this (pseudocode):
ByteBuffer buffer = ...;
eturned by sendClose() and be done with it.
But onClose() should return a CS, or you decided not to ? If so, can
you detail why, FTR ?
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal p
always offering a close code in the
API (and thus get rid of the Optional).
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
ebSocket
Connection Close Code_ is considered to be 1005."
I am not opposed to have a utility method sendClose() parameterless,
but I don't think that it's worth an Optional in onClose(), given the
semantic defined by 7.1.5.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally,
n has the
meaning of a 1005 code.
If you remove the parameterless sendClose() from the API, you don't
need the Optional anymore, and things will be much simpler.
My point being: let's clean the API to the bare minimum required,
removing stuff until there is nothing left to take away.
Th
bytes long.
The requirement of handling its payload asynchronously can be perhaps
dropped: the implementation can just copy those bytes and pass them to
the application, and not worry about buffer recycling.
In any case, your call, I'm fine with either solution.
--
Simone Bordet
http://bor
nClose(), but not to onPing(), nor to onPong().
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
I don't recall if extensions have been ruled out ?
Browsers seem to have settled at implementing permessage-deflate.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and
pResponse.multiProcessor::onStart's return
> type (from BiFunction<..., Boolean> to BiPredicate), to building on the
> j.u.c.Flow API & eliminating HttpResponse.MultiProcessor. So I'm wondering
> what's still on on the table for JEP 110 w.r.t. API changes?
I second
Hi,
On Tue, May 10, 2016 at 2:03 PM, Pavel Rappo wrote:
> Hi Simone,
>
>> On 4 Apr 2016, at 20:07, Simone Bordet wrote:
>>
>> In my experience, once you get rid of exception throwing in async API
>> everything becomes much simpler, especially "dee
ry quick look, but exception throwing, thread dispatching,
multi-nested synchronization, incorrect handling of non-blocking
writes (if I understand the code correctly) are still there.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
I'm presenting the API at a conference this week, would be great to
have a 10k meters view of the availability for early adopters.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with opti
Hi,
is there any plan to make the new HTTP/2 and WebSocket client
implementation replaceable via a ServiceLoader mechanism ?
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal
code ?
SSLEngine.getApplicationProtocol() seems only to be used for debugging ?
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be fla
ent has been received. I find this confusing.
I would rather remove this method (to keep only bodyAsync()), and
provide a utility class that has a blocking behavior when passed to
bodyAsync(), something like:
BlockingBody bb = ...;
response.bodyAsync(bb);
T body = bb.get();
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
#x27;s really confusing to review :/
Maybe you can clarify why it has been implemented in this hybrid way,
to then rewrite it asynchronously ?
It will help reviewers (at least me) to understand the implementation
choices (which now appear as "wtf" moments).
Thanks !
--
Simone Bordet
h
e API which are protected via dispatches to other
threads (that then block), but the I/O.
Is this deliberate ? I was under the impression the HTTP client wanted
to be non-blocking at its core ?
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design
g your HTTP/1.1 patches, then the HTTP2 patch.
Is that ok ?
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
eview in an IDE rather than in textual mode, but I
have not found instructions on how to apply a webrev to a source tree.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and r
ons).
4) Where possible, try to avoid the use of the modulo operator % - it
is known to be really slow.
>From what I saw, you can probably get by using power of twos and bit
shifting and masking.
It does make the code a little more unreadable though. Your call.
Thanks !
--
Simone Bordet
http
ifferent in their speed. How would you suggest one should organize
> and
> scale this?
You have to define what you mean by "organize and scale", and what is
the real problem you are trying to solve.
I would not start worrying about this until the implementation is
simple and effi
ould hurt
applications that do not block - and we are going towards more and
more of this kind of applications.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and relia
Hi,
On Mon, Apr 4, 2016 at 5:35 PM, Chris Hegarty wrote:
>>> On 3 Apr 2016, at 18:43, Simone Bordet wrote:
>>> Threading.
>>> ---
>>> WebSocket.sendXXX() calls
>>> MessagePublisher.send(), which dispatches a to
>>> MessagePublisher.
subclasses for application or
implementation failures, but Exception or subclasses instead.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique
s something deliverable, perfect, why
> can't I proceed with reading the next chunk of data?
When the read buffer has no more space, you are going to require a
read interest for no reason.
If you are otherwise compacting the buffer, you will run into the data
corruption problem I mentioned.
Bot
mentation needs
a major overhaul to simplify it.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
handshake
Is that right ?
In that scenario, what is the use of
SSLEngine.getHandshakeApplicationProtocol() ?
Also, I don't understand how the above could work for SSLSocket ?
Can someone write down the steps a client and a server should do to
actually use ALPN with SSLSocket ?
Thanks !
--
be as close as possible to ReactiveStream, then
just use the Flow API.
LongConsumer is of course not Flow.Subscription. Half mimicking the
Flow API does not bring any good.
And with this I really hope you are not going to extract out of
WebSocket also the cancelling/closing part to separate more concerns
thod into WebSocket, you get
exactly that: the write part along with the flow control and
cancelling part.
In ReactiveStream Publisher and Subscription are divided to support
multiple Subscribers.
In WebSocket there is no need to, hence, no need to split them.
--
Simone Bordet
http://bordet.blo
in the implementation, and you will not painting yourself in a corner
with CharBuffer.
Today you can use charset encoders, tomorrow you may use something
more optimized that does not need CharBuffer.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and
* to buffer pool ...
}
});
}
At that point, the return value of onText() could well be a CF like
it already is, no ?
The implementation would just need to test for null, but then never
actually use the returned object wrapped by the CF.
What do you think ?
--
Simone Bordet
n less and clearer
code), I am interested in learning from it.
> As for the API, well CompletableFuture is surely more nice compared to a bare
> Consumer. But let me try to implement both things and we could choose later.
> We probably don't want to double the number of sending me
keep WebSocketException only.
The subclasses also break an "implicit" naming convention where
exceptions class names always have the "Exception" suffix. The JDK
consistently use this naming convention apart for some 1.0 class for
historical reasons (e.g. ThreadDeath).
Than
n where
exceptions class names always have the "Exception" suffix. The JDK
consistently use this naming convention apart for some 1.0 class for
historical reasons (e.g. ThreadDeath).
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
more
an implementation detail or something you want to configure in a
concrete implementation class, rather than in the API.
IMHO there are other ways to solve the same problem than exposing a
ByteBuffer pool API inside a WebSocket API.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
--
Hi,
On Fri, Oct 9, 2015 at 3:18 PM, Pavel Rappo wrote:
>> On 8 Oct 2015, at 20:51, Simone Bordet wrote:
>> For example, this is going to surprise users (simple echo):
>>
>> onBinary((ws, bytes, last) -> {
>>ws.sendBinary(bytes, last, null, (_, failure)
}
default void onError(WebSocket ws, Throwable failure) { }
end
enum CloseState { OPEN, REMOTE, LOCAL, CLOSED, ABORTED }
end
I hope it gets a second consideration.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug
to be configured in HttpClient ? Likewise for cookies and
headers ?
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
cklist/Comparator
>
> 2. set/getApplicationProtocols() back to SSLParameters.
Have you implemented this solution already ? Also for clients ?
Do you have feedback on actually implementing ALPN in this way ?
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the arch
Failed to proof-read.
I meant "there is *no* timeout for async calls either" below.
Thanks !
On Mon, Sep 28, 2015 at 3:08 PM, Simone Bordet wrote:
> Hi,
>
> On Mon, Sep 28, 2015 at 2:50 PM, Michael McMahon
> wrote:
>> We might reconsider this. Currently ther
which is of
course against an async API and therefore not a viable solution.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be fl
o write when using
Future.get(time) is just cumbersome, I would advice against any usage
of Future methods in the API.
CompletableFuture is fine, as long as you don't use the Future methods.
If an application wants to use Future methods, they are on their own,
but at least they are not forced to.
-
no idle timeout, no
total (request + response) timeout, which are in my experience the 3
most requested features about timeouts.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
s (CompletableFuture.get(time) is obviously not the
right semantic)
are blockers for me.
The other points in my previous message are less blockers, but I would
still ask to consider them.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design
an implementation already ? That would help.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
and also much more flexible.
Well, I kinda like it, but I have strong reservations that it cannot
really "negotiate" the application protocol, meaning that if one
application protocol fails, try the next, and then the next and so
forth until one succeeds (or they all fail).
Thanks !
--
H1 and H2 for
ap.matches(), but in general these will be implemented by application
code.
For an application that wants to support H2, this boils down to the
first 2 lines, the rest is in the JDK.
Thanks !
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and
tions, exactly
because the application decides whether to accept or not the
combination of application protocol, cipher, etc.
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
m the HTTP/2 spec.
Yes, there was an answer to Bradford's email:
https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0160.html.
The answer is "yes".
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug
avor ap1 *and* c2, you have to decide what is more
important between the two, because you cannot have both.
I don't see any problem, really.
That the results are different, sure, but they are predictable.
When the configuration uses one comparator, it will always be that
result, and same for t
etend that ALPN
> wasn't recognized.
Are you saying that every application has to write its own TLS parser ?
Would not that be overkill and full of potential security issues if
one does not get the implementation strictly correct ?
Also, what if the JDK implementation refuses to use the
to prefer 128 bits or lower to favor performance,
but also do HTTP/2.
The H2 comparator will sort the blacklisted at the end.
Among the good ones, they all compare == 0 for the H2 comparator.
That is where the second comparator will kick in, grep the cipher name
for the bits number and sort them accor
xplorer.java
Can you expand on how such approach would look like ? Seems overkill
to me, and all in the hands of application developers ?
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performa
1 - 100 of 116 matches
Mail list logo
