A remoting gateway should be able to understand the following headers:
The client understands the following headers:
The client may ask the server to send back debugging information. While the client sends this request as a header, the server should respond by a body. This header is modified by the NetConnection debugger. See Debug information for details.
The client can request that the server consider a client’s credentials. This should trigger an authentication routine. The data will contain an object with keys ‘userid’ and ‘password’. The server should not directly respond to a Credentials header by sending a body with the authentication results. Instead they should keep the authenticated-for role in a session variable and throw an error when the client attempts to call a method without the right role. The credentials headers is persistent, meaning the user and password can be passed several times between the client and the server. The gateway can request to clear the header using a RequestPersistentHeader header.
The service browser (a windowSWF included in Remoting) may request service descriptions from the server. The gateway does not have to implement this functionality, however it can be nice for the end-user to take advantage of such a function.
The server can request that the client set a server on its end. This is implemented in mx.remoting.Connection. The ‘data’ should be set to an object containing the keys name, mustUnderstand and data. If the key already exists in the connection headers, the header is replaced. Thus the server can use this mechanism to clear Credentials headers if it wishes.
This header forces the client to append a string to the gateway url. This can be used to hardcode the session id into the gateway url. ‘data’ should be set to an UTF string containing the value to append.
Similar to AppendToGatewayUrl, however replaces the whole gateway url instead of appending to it.