Oliver Zeigermann wrote:
It seems everything goes well with Slide, but Word expects a different answer when it creates the new file. This is the interesting part of the communication:
Word sends ----------
LOCK /slide/files/Word-Doc9.doc HTTP/1.1 Content-Language: en-us Accept-Language: de, en-us;q=0.2 Content-Length: 176 Timeout: Second-180 Translate: f Content-Type: text/xml Depth: 0 User-Agent: Microsoft Data Access Internet Publishing Provider DAV Host: milhouse.finix.de:8888 Connection: Keep-Alive Cookie: JSESSIONID=F11A32323ECA727AA55C2FF7A65056C2
<?xml version="1.0" encoding="UTF-8" ?> <lockinfo xmlns="DAV:"> <locktype> <write/> </locktype> <lockscope> <exclusive/> </lockscope> <owner>olli</owner> </lockinfo>
Slide replies -------------
HTTP/1.1 200 OK Lock-Token: <opaquelocktoken:140e3a8b47f584338918bf8a2aa9e311> Content-Type: text/xml; charset="UTF-8" Transfer-Encoding: chunked Date: Mon, 22 Mar 2004 14:24:32 GMT Server: Apache Coyote/1.0
<?xml version="1.0" encoding="UTF-8"?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype>
<D:write />
</D:locktype>
<D:lockscope>
<D:exclusive />
</D:lockscope>
<D:depth>0</D:depth>
<D:owner><![CDATA[olli]]></D:owner>
<D:timeout>Infinite</D:timeout>
<D:locktoken> <D:href>opaquelocktoken:140e3a8b47f584338918bf8a2aa9e311</D:href>
</D:locktoken>
<D:principal-URL>
<D:href>/slide/users/unauthenticated</D:href>
</D:principal-URL>
</D:activelock>
</D:lockdiscovery>
</D:prop>
Word sends ----------
PUT /slide/files/Word-Doc9.doc HTTP/1.1 Content-Language: en-us Accept-Language: de, en-us;q=0.2 If: (<opaquelocktoken:140e3a8b47f584338918bf8a2aa9e311>) Translate: f Content-Length: 0 User-Agent: Microsoft Data Access Internet Publishing Provider DAV Host: milhouse.finix.de:8888 Connection: Keep-Alive Cookie: JSESSIONID=F11A32323ECA727AA55C2FF7A65056C2
Slide replies -------------
HTTP/1.1 204 No Content ETag: f8ced3ac54ed3bfb83510e97d9aa8506 Date: Mon, 22 Mar 2004 14:24:32 GMT Server: Apache Coyote/1.0
Anyone any ideas, what Word may expect as an answer?
Thanks in advance,
Oliver
When we had similar problems, we just compater our traces with traces obtained IIS and Apache/mod_dav.
In general I think MSDAIPP.DLL is very picky about LOCK properties; in this case I'd take a look at the timeout (not being accepted) and the CDATA-escaped owner name (although this really really shoudln't matter). Why is it CDATA-escaped anyway?
Hope this helps,
Julian
Thanks, Julian, you actually were right! There was a hack that made null locks never expire. When the timeout is accepted correctly everything works fine.
This makes me wonder, is it save to remove this hack? Could anyone comment on this?
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
