You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A check in REPP was so far defined as HEAD verb, which means that all additional extension information would have to be encoded into either query parameters or headers.
In both of the cases one would have to encode the whole XML into a query parameter (base64 or just url-encode) -> request URI string limit might be an issue
Same for headers - also here maximum header length might be an issue.
Other option would be to have a version of query commands with body. It could be like POST /{collection}/_{command} say POST /domains/_check in this case.
Downside is that in this case servers would have to implement two ways of serving the same thing.
Same situation with command. Here GET also should not contain any body, or at least this is what http RFC would not recommend to use.
Opinions or other ideas?
The text was updated successfully, but these errors were encountered:
encoding the info from the extension into headers and query parameers is going to be a pain.
i don't see any other way than to also allow for the use of POST method for a query command in those cases where a payload message (from extension) has to be sent to the server by the client.
the server may also choose not to implement this by not using this extension (who uses this anyway?) or any extension that requires anything other than HEAD method for a check command.
EPP allows for extending query commands as well.
Example (from IANA EPP extension repository) https://www.verisigninc.com/assets/defensive-registration-mapping.pdf:
3.1.1 EPP Command
Schema:
A check in REPP was so far defined as HEAD verb, which means that all additional extension information would have to be encoded into either query parameters or headers.
In both of the cases one would have to encode the whole XML into a query parameter (base64 or just url-encode) -> request URI string limit might be an issue
Same for headers - also here maximum header length might be an issue.
Other option would be to have a version of query commands with body. It could be like
POST /{collection}/_{command}
sayPOST /domains/_check
in this case.Downside is that in this case servers would have to implement two ways of serving the same thing.
Same situation with command. Here GET also should not contain any body, or at least this is what http RFC would not recommend to use.
Opinions or other ideas?
The text was updated successfully, but these errors were encountered: