CapTP on HTTP - Revision history

Kevin Reid: yes, different mime type

Kevin Reid — Mon, 01 Jun 2009 14:38:53 GMT

yes, different mime type

New page

''Motivation: [[Caja-CapTP]] attempts to reuse web protocols to minimize the amount of low-level code (parsers, ...) or access (TCP, ...) it requires.''

This page will define a protocol for transporting a CapTP connection over HTTP.

== Identification and security ==

For the protection of swiss numbers and private data, this protocol should only be used over a secure connection (HTTPS, relying on certificate authorities, or [[HTTPSY]]) or a relied-upon network.

The format of a serialized SturdyRef in this protocol is:

http[s[y]]://.../''arbitrary''#''swissNum''

The [[VatID]] data is everything but the fragment, unless HTTPSY is used in which case the host:port information is omitted. {{XXX|formalize this}}

{{XXX|specify encoding of swissNum}}

== Connections ==

Unless otherwise specified, all requests and responses are JSON text following Waterken conventions {{XXX|link to docs}} for types and hyperlinks, of media type (MIME type) <code>application/captp+json</code>. ''Rationale for having a distinct media type: Web protocol design principles say that clients should not need prior knowledge that any given URL is a CapTP-related URL.''

After a connection is established, all CapTP messages are sent as HTTP POST requests to connection-specific ''receivers'', which are web resources identified by URLs.

To open a CapTP-on-HTTP connection, the initiating vat sends a POST request to the above URL; the request body consists of the URL of the initiator's receiver. {{XXX|Specify how the server obtains and verifies the client's VatID.}} The successful response consists of the URL of the server's receiver. {{XXX|Specify tiebreaking scheme.}} All communication from then on is symmetric.

[[Category:Pluribus]]

Kevin Reid: explain motivation a bit better

Kevin Reid — Mon, 01 Jun 2009 04:07:15 GMT

explain motivation a bit better

←Older revision		Revision as of 04:07, 1 June 2009
Line 1:		Line 1:
-	''Motivation: [[Caja-CapTP]] attempts to reuse web protocols to minimize the amount of low-level code it requires.''	+	''Motivation: [[Caja-CapTP]] attempts to reuse web protocols to minimize the amount of low-level code (parsers, ...) or access (TCP, ...) it requires.''

	This page will define a protocol for transporting a CapTP connection over HTTP.		This page will define a protocol for transporting a CapTP connection over HTTP.

Kevin Reid at 03:59, 1 June 2009

Kevin Reid — Mon, 01 Jun 2009 03:59:59 GMT

←Older revision		Revision as of 03:59, 1 June 2009
Line 1:		Line 1:
-	''Motivation: [[Caja-CapTP]] attempts to reuse web protocols to minimize the amount of low-level code ~~(parsers, ...) or access (TCP, ...)~~ it requires.''	+	''Motivation: [[Caja-CapTP]] attempts to reuse web protocols to minimize the amount of low-level code it requires.''

	This page will define a protocol for transporting a CapTP connection over HTTP.		This page will define a protocol for transporting a CapTP connection over HTTP.
Line 17:		Line 17:
	== Connections ==		== Connections ==

-	Unless otherwise specified, all requests and responses are ~~JSON text~~ following Waterken conventions {{XXX\|link to docs}} for types and hyperlinks~~, of media type (MIME type) <code>application/captp+json</code>~~. ~~''Rationale for having a distinct media~~ type~~: Web protocol design principles say that clients should not need prior knowledge that any given URL is a CapTP-related URL.''~~	+	Unless otherwise specified, all requests and responses are <code>application/json</code> entities following Waterken conventions {{XXX\|link to docs}} for types and hyperlinks. {{XXX\|Should we define our own more specific mime type?}}

	After a connection is established, all CapTP messages are sent as HTTP POST requests to connection-specific ''receivers'', which are web resources identified by URLs.		After a connection is established, all CapTP messages are sent as HTTP POST requests to connection-specific ''receivers'', which are web resources identified by URLs.