Synchronous Updates Manual
Syncupdates is the facility of the RIPE Database to enable updates synchronously, meaning, the result is returned immediately to the user. It is meant to be an infrastructure for applications which need to update the RIPE Database and receive the result afterwards.
This document describes the basic usage of the infrastructure that is sends the update and receives the result. An interface can easily be created in any language that has support for "http".
The service can be used by connecting to
http://syncupdates.db.ripe.net/ for the RIPE Database, and
http://syncupdates-test.db.ripe.net for the RIPE TEST database.
SSL connections are also available for both databases.
(Note: these URLs will not work properly with a standard browser. Please see this page for a sample form based client for syncupdates.)
The syncupdates frontend is actually implemented as a CGI script, which accepts input as either a POST or a GET method. It responds with the response header and the acknowledgement (if any) in text/plain format.
Sending The Update
Syncupdates accepts the following variables:
- DATA This variable should contain the actual update message.
- NEW This variable can be either yes or no. If it contains yes, the update will fail if it contains changes to existing objects.
- HELP This variable can be either yes or no. If it contains yes, the help message of the whois server will be given as the output.
- ORIGIN This variable should contain the the IP address of the machine submitting the update if it's different from the IP address that is sending the update. It is useful for proxy applications.
For general information about the RIPE Database, please see the RIPE Database Reference Manual.
Receiving The Input
After composing the input and sending it as a POST or a GET request, the server will return the usual http headers and the body if an acknowledgement exists.
The first line of the header will give the result of the transaction, in the form of:
HTTP/1.1 (code) (message)
where (code) is a 3-digit number which is a code for the message. The first digit of the code denotes the type of the message. The rest of the digits are unique for all messages:
- 2XX denotes a successful transaction,
- 3XX denotes that further action needs to be taken by the user agent in order to fulfill the request,
- 4XX denotes that the request could not be understood by the server due to malformed sy