Re: [regext] Comments to the feedback about epp-over-http

[Mario Loffredo <[e-mail]>]

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: [phone]
Web: http://www.iit.cnr.it/mario.loffredo