Subject: FW: RE: Does zope mess with the body in a GET?

From: Jim Whitehead <[email-masked]>
Date: Mon, 15 Nov 1999 16:20:11 -0800

Another message caught by the spam filter.

- Jim

-----Original Message-----
From: Brian Lloyd [mailto:[email-masked]]
Sent: Monday, November 15, 1999 11:07 AM
To: 'Jim Davis'
Cc: [email-masked]
Subject: [Moderator Action] RE: Does zope mess with the body in a GET?

> I did a PUT to foo.html.  I sent 51 characters
> "Despite the name, this is a <B>plain text</B> file."
> 
> when I did a GET I got back 71 characters, 
> 
> "<html><head></head>
> Despite the name, this is a <B>plain text</B> file."
> 
> Looks to me like Zope added those HTML elements for me.  this seems
> undesirable.
> 
> What is also bizarre is that if I do  HEAD, I get back length of 51.
> 
> So I think Zope must be adding them when I do then GET.

It is - this is a documented "feature" from a long time ago in 
Zope's evolution. Because Zope is a pretty dynamic multiprotocol
object environment rather than a simple file server, there are a 
number of similar issues that boil down to an impedence mismatch
between the expectations for dynamic vs. static resources and
(in some cases) the need to maintain b/w compatibility :(

This is especially true regarding "templatish" objects that may 
or may not be thought of as "content" depending on what you are 
doing with them. I suspect that this is also an issue with ASP, PHP,
et. al. too - it would be great to be able to manage these things 
in a standards-based way, but currently DAV is very static-file 
centric in its approach. I'm not knocking that - but it makes 
the practical use of DAV pretty limited on sites that can't get
by on just static files. I've been hoping that we can wrangle 
the time to make some contributions in this area.

> For what it's worth, after the PUT I also did  PROPPATCH to 
> set the type to
> text/plain.
> But that seemed to have no effect
> 

I'll take a look at that. Thanks!

Brian Lloyd        [email-masked]
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com

---

From: Brett McCormick <[email-masked]>
Date: Mon, 15 Nov 1999 17:40:06 -0800 (PST)

> the time to make some contributions in this area.

This situation has already been considered.  Section 5.4 of RFC 2518
(the webdav spec) is titled "Source Resources and Output Resources."

The content returned by zope would be considered the "output
resource."  Since it is dynamically generated, you shouldn't be able
to PUT the new content at all.  You need a separate URI to refer to
the source resource.

Frustrating, I know.  I am having to deal with the same issues, since
I'm modifying my HTML before its being sent out.  The best solution
I've come up with is to use another URI that is mapped directly to the
filesystem.

There's a way to link from the output resource to the source resource
on webdav compliant servers, I would check the above section of the
RFC for details.

--brett

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Tue, 16 Nov 1999 14:04:07 +0100 (CET)

On Mon, 15 Nov 1999, Brett McCormick wrote:

....
 
> (the webdav spec) is titled "Source Resources and Output Resources."
 
But still, beside this as soon as you hit dynamic content you have two
problem's hitting you; you cannot 'PUT' to the target URI so easily
anymore as it has different semantics; which is more than just the content
and something as simple as, say, renaming a top level directory reliably
can in fact trigger locking on a virtually infinitive space of URI's
deeper down.

Dw

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Tue, 16 Nov 1999 09:02:25 -0500

From: Dirk-Willem van Gulik <[email-masked]>

   ... as soon as you hit dynamic content you have two
   problem's hitting you; you cannot 'PUT' to the target URI so easily
   anymore as it has different semantics;

When trying to author a dynamic resource, I believe that it makes much
more sense to first do a GET to the source definition of that dynamic
resource.  And then the PUT would logically go back to that source
definition, not to the dynamic resource.

   which is more than just the content
   and something as simple as, say, renaming a top level directory reliably
   can in fact trigger locking on a virtually infinitive space of URI's
   deeper down.

I believe it makes much more sense to LOCK the source definition of a
dynamic resource, rather than the dynamic resource itself.  So lock
checking would only be performed on the (finite) source definition space.
In addition, it is likely that the location of the dynamic resource tree
will be "frozen" at a specific URL, so you wouldn't be able to MOVE that
tree anyway, irrespective of any locking behavior.

Cheers,
Geoff