RE: Visibility (was Re: Introducing the Service Oriented Architec tural style, and it's constraints and properties.

Ok, I mis-spoke below.  On the basis of some private correspondance I
discovered that the URL's themselves are in fact encrypted in HTTPS.
Sorry, I didn't know that.  So I talked to one of our security people
and they indeed have no concerns about what information is in the URL's
going over HTTPS, other than the length of the string.  (They tell me
they routinely have trouble with apps overflowing the restrictions,
which in practical terms vary from 2-8 K.  I have confirmation from
another source that 2048 is still a common restriction in practice).  I
also discovered that the URL's being encrypted means that the requests
cannot be cached along the way, but that they might be cached internally
to our company by the servers that provide the SSL encryption.

They are, however, objecting on security grounds to the use of GET's
INTERNAL to the company that are not going over HTTPS.  I incorrectly
extrapolated from that to B2B transactions.  Sorry.

I believe, however, that I am correct in saying that nobody around here
has the slightest interest in using the REST style nor in the debates
surrounding the issue.  Everybody that I know in the business community
is MORE than happy to put verbs into the bodies of messages.

As long as I was talking to one of our experts, I asked him about the
issue of filtering things in the firewall based on content, which I
believe is another part of this thread.  He confirmed that IF you want
to do this, in practical terms you'd better be looking at stuff that's
in the URI -- because that limits how much parsing you need to do.  I
believe he feels that having to parse the body of the message would
cause severe performance problems.  He said they have lots of tools
available that work on the URI's, but that they do very little of it,
preferring to do things at the application level.  He said that if
somebody came to them and wanted something like that they'd try to talk
them out of it, mostly because maintenance is a lot harder at the web
switch level and they are trying to keep those functions as clean as
possible.  You have a lot more tools to debug things at the application
level.  The one type of thing that he said might be attractive at the
web switch level is examining the URI to see if it's an image and
routing all images to an image server.  There are apparently potential
performance or convenience gains to doing this.  We kicked around the
idea of analyzing the URI's for web services.  I believe that the kinds
of things he might find plausible had a lot more to do with performance
than security or functionality, and he was pretty dubious about wanting
to do any of them anyway.  Again, much better debugging tools at the
application level was a key driver.  To summarize, I believe that the
feeling was, "Yes, putting stuff in the URI gives it better visibility,
but we don't really want to use it".

-----Original Message-----
From: Cutler, Roger (RogerCutler) 
Sent: Tuesday, February 25, 2003 11:37 AM
To: Champion, Mike; www-ws-arch@w3.org
Subject: RE: Visibility (was Re: Introducing the Service Oriented
Architec tural style, and it's constraints and properties.



OK, since you are appealing to me, I will cheerfully set myself up:

I think that putting just about anything in the URL's would be frowned
upon very seriously by the people concerned about security, at least
those that I am familiar with.  To heck with the identity of the user --
the nature of the service itself would probably be considered sensitive.
For example, if we send out 1000 HTTP messages to the same URL, with the
nature of the operation encrypted in the body of the message (BUY, SELL,
QUOTE PRICE, etc) I don't think there is much problem.  But if we send
250 to http://BUY and 300 to HTTP://SELL and so on, I think that in
itself would be considered unacceptable.  OK, so maybe if A is dealing
with X, then they previously agree that http://abra means BUY -- and for
B dealing with X they agree that http://cadabra means BUY -- maybe
that's OK in terms of security (I don't really know), but it sure
doesn't look very late bound or, in fact, very different from encrypting
the BUY in the message.  I pass on whether that approach would be
RESTful.

Our security people REALLY don't like putting stuff into URL's.  I think
that the level of interest in the REST style of implementing business
processes over the Web is practically nonexistent, at least in the
environments with which I am familiar.  There is similarly virtually no
interest in these debates, as far as I can tell, either.  

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Tuesday, February 25, 2003 11:06 AM
To: www-ws-arch@w3.org
Subject: RE: Visibility (was Re: Introducing the Service Oriented
Architec tural style, and it's constraints and properties.



> 
> I'm not sure about this part.  First off, how RESTful would it be to 
> encode the identity of the user in the URI (unless the resource IS the

> user, but I don't think that's what you mean).  I'll appeal to Mark on

> this one.

I'll appeal to Roger, since he lives closer to the Real World than
either Mark or I do :-)  I was thinking specifically of the issue he
raised with respect to GET being frowned upon by many IT shops because
it was seen as potentially exposing confidiential information in
intermediaries, browser histories, etc.  Perhaps a thorough
understanding of REST principles wouldn't lead to this problem, but,
uhh, the sysadmins out there seem to barely understand the Web as it is,
much less the vision of the Web as it could be.

Received on Tuesday, 25 February 2003 16:13:02 UTC