- From: <ccjason@us.ibm.com>
- Date: Tue, 4 Aug 1998 09:48:30 -0400
- To: w3c-dist-auth@w3.org
> >I just want to recheck how Server Side Includes work so that we are doing > >them is similar ways... > > > >Traditionally, one PUT's a *.shtml file at a specified URL and GET requests > >to that URL result in the out put of executing the SSI. > > I wouldn't allow that. If the server is maintaining the source file > under a different URL than the GET,... Roy, You say, "IF the server is maintaining the source file under a differnt URL than GET..." That's what I said in my proposal, but is that what we're typically going to be seeing? I have no idea. It's just the first WEBDAV'ish way that I thought of for handling it. Let me know if your expectations are. Anyone. > then a PUT on the latter URL should > result in an error or redirection to the source URL. I think I understand what you're saying here. "latter URL" here means the one who's GET results in processing of the SSI. > The server can > determine that from the URL and content of the PUT. Otherwise the > author is likely to be confused about what is being authored. I don't think I understand what you're saying here. Determine what? Determine if it's an old fashion PUT or a WebDAV PUT? I'd appreciate it if you restated this. I don't know what "that" refers to. > This is also a key issue for deployment, since older tools might be > mistakenly used to modify and PUT the generated content rather > than the source content. It also makes access control easier. Again. I'd appreciate it if you said what "It" is... and if not then obvious, why "[IT] makes access control easier". J.
Received on Tuesday, 4 August 1998 19:22:30 UTC