[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 6.1) SOAP Proxy
On Dec 18, 2003, at 4:05 PM, Scott Lawrence wrote:
Ted Goddard <ted.goddard@windriver.com> writes:
The NETCONF/SOAP draft contains the following text:
3.6 Managing Multiple Devices
When a server is acting as a proxy for multiple devices, the URL
for
the HTTP POST can be used to indicate which device is the target.
It
may also be desirable to use the HTTP POST URL as a means for
selecting from multiple virtual devices on a single device.
First, that's not a change from HTTP anyway - to traverse a proxy, you
send it a URL that refers to some other system.
Good point, although the NETCONF usage here would not be restricted to
HTTP -- for instance, a NETCONF "aggregating" server could offer a
SOAP interface to enterprise systems but actually communicate with the
NETCONF devices over BEEP.
There are other ways to deal with this, however -- my impression
is that there is some desire to remove the idea of "session" from
NETCONF/SOAP, and the above paragraph is compatible with that.
Either that, or make the session explict rather associating it with
the connection. Any message within a session carries the session
identifier. If you're going to support more than one transport, then
this removes a required service from the lower layer.
The idea of putting a session identifier as an attribute of <rpc>
has been discussed ... the SOAP draft currently identifies
the session in the SOAP request-URI. We are hoping to understand
the value of sessions better from NANOG feedback.
Timeouts are not the only reasons a proxy might close connections, so
I wouldn't bet too heavily on them.
Agreed; although could you characterize some of the other typical
circumstances? Proxy load could certainly cause proxies to drop
connections.
For standard HTTP proxies, you should be able to tunnel through using
CONNECT; and if you keep sessions, then that would be a very good
idea. How to do this is described in RFC 2817 (the title implies that
it's about HTTP security, but everything it says is applicable to any
use of HTTP that requires an end-to-end transport).
Excellent reference, thanks. The CONNECT tunnel appears to have much
better behaviour than proxied HTTP requests. The worst case would
seem to be where the connection between the agent and the proxy was
closed, but the connection between the manager and the proxy
remained open, causing the manager to block indefinitely (and this
would really be due to a bug in the proxy). Are there other failure
cases to consider carefully?
Thanks,
Ted.
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>