- From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
- Date: Tue, 25 Feb 2003 15:12:21 -0600
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org
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