Hi Thomas,
thanks a lot for your interest as well as your attempt to mediate
between James's position and mine. Very appreciated :-)
Starting an HTTP session when receiving an EPP command other than the
Login command is in .it experience (but I can speak on behalf of .pl
too) very inefficient because you can't immediately lock the HTTP
session to the Registrar.
It also has some implications on security : to start a session on a
server, in one case you need only an allowed IP address; in the other,
you need an allowed IP address, valid credentials and you shouldn't
exceed the limits of EPP sessions per Registrar.
In addition, while TCP client needs to establish a connection before
sending the EPP Login command since the transport protocol is
connection-oriented, an HTTP client doesn't need to do because the
protocol is not connection-oriented (even if it uses connections). So
why should an HTTP client be required to send a useless HTTP request?
Just to operate in the same way of EPP over TCP? It's a nonsense.
With regard to the compliance with RFC5730, the only difference with the
proposed approach is that a client MAY send an Hello via POST before
sending a Login. Anyway, the EPP session starts after a successful Login
as defined in RFC5730 itself.
Is this approach less compliant to RFC5730 than James's one? Maybe. For
sure it's more efficient (at least both in .it and .pl contexts)
Best,
Mario
Il 31/03/2022 14:36, Thomas Corte (TANGO support) ha scritto:
Hello Mario,
On 3/31/22 13:52, Mario Loffredo wrote:
Hi James,
For what I have understood, your implementation is based on the
assumption that once the HTTP Connection is established, it is used
for the transit of all the HTTP requests of an EPP session, starting
from the Login and ending with the Logout.
Consequently, you rely on keeping the HTTP connection alive as long
as the EPP session works. Correct?
If so, in my opinion, that is a wrong assumption.
Clients should not be forced to keep alive the HTTP connections if
HTTP allows to maintain HTTP sessions alive across a sequence of
HTTP connections.
...
I might be wrong (it was hard to follow the entire discussion, mostly
due to the lack of consistent e-mail quoting in the thread), but I
don't think there really any disagreement here between James and you.
As James speaks of HTTP Session Cookies in many places, I don't think
he's suggesting that the connection management should be required to
make use of any HTTP keepalive features. Instead, I think that you're
both agreeing that the EPP "session" over HTTP is simply managed by an
initial cookie given to the client, which he'll need to send along
with any subsequent request to indicate that it belong to the same
session. This also means that, unlike with TCP, an EPP session over
HTTP can indeed survice a server restart, as long as the server can
retrieve sessions from permanent storage after its restart.
I think the only point of contention here is when exactly the cookie
is supposed to be returned by the server, namely
a) at the time the very first request without a session cookie is
received (i.e., when the EPP client sends a <hello>?) OR
b) only after the first <login> command is received with correct
credentials
My preference would be a) as it more closely resembles the TCP
transport (where the connection itself is established before the first
valid <login>).
Best regards,
Thomas
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
