After Jim Goulds presentation on implementing EoH and EoQ I was inspired to
start hacking on the two protocols in our own EPP server implementation, while
doing so, some questions about EoH popped up.
In the EoH draft there is a couple of MUSTs for the client when sending a
request:
- The GET request MUST include "application/epp+xml" (Appendix B of [RFC5730])
in the "Accept" HTTP header.
- An EPP client MUST send all commands as HTTP POST requests (Section 6.4 of
[RFC9110]).
- Each POST request MUST include the HTTP session identifier in the "Cookie"
header and "application/epp+xml" in the "Accept" header.
The current draft provides the following for dealing with misbehaving clients.
Servers MUST NOT use HTTP return codes to signal clients about the
failure of the EPP commands. The HTTP code 200 MUST be used for both
successful and unsuccessful EPP requests. Servers MUST use HTTP codes
to signal clients about the failure of the HTTP requests.
Servers MUST return an EPP 2002 response (i.e. Command use error) if
the client issues an EPP command with either an empty or an invalid
HTTP session identifier.
The only thing covered in detail is what should happen if an EoH server
receives a request without a session identifier. I think it would be useful for
the spec to be clear on what a server should return if any
of the requirements above are broken.
My 2 cents on what a server should do:
- A request with the correct Accept header but wrong HTTP method (say we get a
PATCH instead of a POST): A server MUST return a 405 HTTP status code
- A request with the incorrect Accept header: A server MAY return a 406 HTTP
status code (I guess one could think of a server that handles EPP and other
stuff so MAY is probably best).
// Eric
The Swedish Internet Foundation
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
