Discussion:
[tw] [TW5] WebDav Saver Observations.
Add Reply
Lost Admin
2017-08-24 13:53:17 UTC
Reply
Permalink
Raw Message
A while back, Jeremy mentioned in another post
<https://groups.google.com/d/msg/tiddlywiki/cO8lYpmAMWE/bKc6mPRZBgAJ> that
TiddlyWiki supports saving via WebDav. I didn't know this existed until he
mentioned it. I do like the idea. Most web server software has support for
WebDav, or there are webdav add-ons. It means I don't need to run PHP (or
node.js) on the server, which significantly reduces the resources needed on
the server. So, I've been experimenting with WebDav.

I've found that it works very well once the web server is set-up properly.

*Using Lighttpd*, it works without issues. Http Basic Auth (or digest auth)
works without issues. I haven't tried, but I don't think there would be
issues using client certificate authentication if one wanted that level of
security on the network link.

*Using Apache*, it also works with basic or digest auth. One interesting
difference, Apache seams to track the last time you loaded the file (get
request) and compares that to the last file modification time-stamp. *If
the last modification is newer than when you loaded the tiddlywiki file,
you get an error and the change doesn't get saved*.

You can (easily) get around this by reloading the file (browser
reload/reread button) after you save the tiddlywiki file. It might be a bit
annoying but it does solve the issue of conflicting edits if two people are
working on it at the same time. On the down side, the 2nd person will have
to re-load the file and re-do all their work (of course browser tabs help
with that).

I don't use nginx, so I haven't tried that one.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/603ae837-720a-4f5c-a4e4-9de40d772783%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Arlen Beiler
2017-08-24 15:39:51 UTC
Reply
Permalink
Raw Message
Does it work in both Chrome and Firefox?
Post by Lost Admin
A while back, Jeremy mentioned in another post
<https://groups.google.com/d/msg/tiddlywiki/cO8lYpmAMWE/bKc6mPRZBgAJ>
that TiddlyWiki supports saving via WebDav. I didn't know this existed
until he mentioned it. I do like the idea. Most web server software has
support for WebDav, or there are webdav add-ons. It means I don't need to
run PHP (or node.js) on the server, which significantly reduces the
resources needed on the server. So, I've been experimenting with WebDav.
I've found that it works very well once the web server is set-up properly.
*Using Lighttpd*, it works without issues. Http Basic Auth (or digest
auth) works without issues. I haven't tried, but I don't think there would
be issues using client certificate authentication if one wanted that level
of security on the network link.
*Using Apache*, it also works with basic or digest auth. One interesting
difference, Apache seams to track the last time you loaded the file (get
request) and compares that to the last file modification time-stamp. *If
the last modification is newer than when you loaded the tiddlywiki file,
you get an error and the change doesn't get saved*.
You can (easily) get around this by reloading the file (browser
reload/reread button) after you save the tiddlywiki file. It might be a bit
annoying but it does solve the issue of conflicting edits if two people are
working on it at the same time. On the down side, the 2nd person will have
to re-load the file and re-do all their work (of course browser tabs help
with that).
I don't use nginx, so I haven't tried that one.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/
msgid/tiddlywiki/603ae837-720a-4f5c-a4e4-9de40d772783%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/603ae837-720a-4f5c-a4e4-9de40d772783%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSSYzJcEc5%2BmdV_69p3dHFCduntKbQ8oDg34e1h%2Bccpq4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-08-24 17:18:09 UTC
Reply
Permalink
Raw Message
Yes. I've tested from Windows with Firefox, MS Edge, MSIE11, Chrome. All
worked.

I've also tested using Android Firefox and Android Chrome as well as Apple
iOS Safari.
Post by Arlen Beiler
Does it work in both Chrome and Firefox?
Post by Lost Admin
A while back, Jeremy mentioned in another post
<https://groups.google.com/d/msg/tiddlywiki/cO8lYpmAMWE/bKc6mPRZBgAJ>
that TiddlyWiki supports saving via WebDav. I didn't know this existed
until he mentioned it. I do like the idea. Most web server software has
support for WebDav, or there are webdav add-ons. It means I don't need to
run PHP (or node.js) on the server, which significantly reduces the
resources needed on the server. So, I've been experimenting with WebDav.
I've found that it works very well once the web server is set-up properly.
*Using Lighttpd*, it works without issues. Http Basic Auth (or digest
auth) works without issues. I haven't tried, but I don't think there would
be issues using client certificate authentication if one wanted that level
of security on the network link.
*Using Apache*, it also works with basic or digest auth. One interesting
difference, Apache seams to track the last time you loaded the file (get
request) and compares that to the last file modification time-stamp. *If
the last modification is newer than when you loaded the tiddlywiki file,
you get an error and the change doesn't get saved*.
You can (easily) get around this by reloading the file (browser
reload/reread button) after you save the tiddlywiki file. It might be a bit
annoying but it does solve the issue of conflicting edits if two people are
working on it at the same time. On the down side, the 2nd person will have
to re-load the file and re-do all their work (of course browser tabs help
with that).
I don't use nginx, so I haven't tried that one.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/603ae837-720a-4f5c-a4e4-9de40d772783%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/603ae837-720a-4f5c-a4e4-9de40d772783%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/e20f570d-2e0b-4dd8-9a90-5fa00e23a486%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
PMario
2017-08-28 13:10:36 UTC
Reply
Permalink
Raw Message
Hi LostAdmin,

That's a perfect reminder, to have a closer look at MS built-in stuff.
WebDav is part of* Internet Information Services (IIS)*, which seems to be
available for up to 20 users for Windows Vista, 7, 8.x and 10. ...

I'm basically interested in a replacement for TiddlyFox and not in a
"internet facing" setup. ...

from win10 user terms
<https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/UseTerms_Retail_Windows_10_English.htm>.


*2. Installation and Use Rights.*
*<snip>*
*d. Multi use scenarios.*
<snip>
(iii) *Device connections*. You may allow up to 20 other devices to
access the software installed on the licensed device for the purpose of
using the following software features: file services, print services, Internet
information services, and Internet connection sharing and telephony
services on the licensed device. You may allow any number of devices to
access the software on the licensed device to synchronize data between
devices. This section does not mean, however, that you have the right to
install the software, or use the primary function of the software (other
than the features listed in this section), on any of these other devices.
So with the right settings, it *may be* possible to activate it for most
windows machines. ... The important phrase is "may be", since nobody really
knows, how crippeld "Home xxx" and OEM Licenses really are.

For those who are courious, *IIS *is the equivalent of the Apache and
Lighttdp servers, that Lost Admin mentioned. ... So it should be possible
to use the stuff for local installations.

... I'm not at home at the moment. So I can't run tests with my machine.
But anyone who is interested, should expolore the docs
<https://docs.microsoft.com/en-us/iis/install/installing-publishing-technologies/installing-and-configuring-webdav-on-iis>,
run some tests and report back here.

Especially interesting: OS version used! So we can see, if it works with
"Home xxxx" licenses. I do have a Win10 Pro, wich I can test on :)

have fun!
mario
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/ce0059f5-2807-435f-b9c3-7ee49f45f0f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Arlen Beiler
2017-08-28 15:08:51 UTC
Reply
Permalink
Raw Message
Can anyone test whether the WebDAV saver works correctly if the file names
have spaces in them, and which server/browser combinations they work on?
Thanks,
-Arlen
Post by PMario
Hi LostAdmin,
That's a perfect reminder, to have a closer look at MS built-in stuff.
WebDav is part of* Internet Information Services (IIS)*, which seems to
be available for up to 20 users for Windows Vista, 7, 8.x and 10. ...
I'm basically interested in a replacement for TiddlyFox and not in a
"internet facing" setup. ...
from win10 user terms
<https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/UseTerms_Retail_Windows_10_English.htm>.
*2. Installation and Use Rights.*
*<snip>*
*d. Multi use scenarios.*
<snip>
(iii) *Device connections*. You may allow up to 20 other devices to
access the software installed on the licensed device for the purpose of
using the following software features: file services, print services, Internet
information services, and Internet connection sharing and telephony
services on the licensed device. You may allow any number of devices to
access the software on the licensed device to synchronize data between
devices. This section does not mean, however, that you have the right to
install the software, or use the primary function of the software (other
than the features listed in this section), on any of these other devices.
So with the right settings, it *may be* possible to activate it for most
windows machines. ... The important phrase is "may be", since nobody really
knows, how crippeld "Home xxx" and OEM Licenses really are.
For those who are courious, *IIS *is the equivalent of the Apache and
Lighttdp servers, that Lost Admin mentioned. ... So it should be possible
to use the stuff for local installations.
... I'm not at home at the moment. So I can't run tests with my machine.
But anyone who is interested, should expolore the docs
<https://docs.microsoft.com/en-us/iis/install/installing-publishing-technologies/installing-and-configuring-webdav-on-iis>,
run some tests and report back here.
Especially interesting: OS version used! So we can see, if it works with
"Home xxxx" licenses. I do have a Win10 Pro, wich I can test on :)
have fun!
mario
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/
msgid/tiddlywiki/ce0059f5-2807-435f-b9c3-7ee49f45f0f6%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/ce0059f5-2807-435f-b9c3-7ee49f45f0f6%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSRPP%2Bdp6ki%3DDOJPKhy%2BSy2pzkHa0vMpAwW7tv%2B-kG7EAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-08-29 23:59:02 UTC
Reply
Permalink
Raw Message
When I created a wiki with a space in the filename and used the webdav saver, it replaced the space with the URL encoding (%20) in the filename on save.

This was tested using my Apache setup from Safari on iOS. Haven't tested other browsers but I doubt they will be any different.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7267242b-b825-453b-b575-5041f655543a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Arlen Beiler
2017-08-30 02:57:34 UTC
Reply
Permalink
Raw Message
And can you reload the renamed file and continue saving to it? Or not?
Post by Lost Admin
When I created a wiki with a space in the filename and used the webdav
saver, it replaced the space with the URL encoding (%20) in the filename on
save.
This was tested using my Apache setup from Safari on iOS. Haven't tested
other browsers but I doubt they will be any different.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/
msgid/tiddlywiki/7267242b-b825-453b-b575-5041f655543a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSRH4Zx0uTi0jkYT_c-%3DkFKfmuVDdukb0LCHutScVPFqJg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-08-31 13:16:14 UTC
Reply
Permalink
Raw Message
"space test.html" got saved as "space%20test.html" which got saved as
"space%2520test.html" which got re-loaded as "space%252520.test.html", so
the %20 encoding doesn't really play nice.

It works but you have to constantly mess with the address when saving. I
would say replacing spaces with underscores in your filenames would be less
painful.
Post by Arlen Beiler
And can you reload the renamed file and continue saving to it? Or not?
Post by Lost Admin
When I created a wiki with a space in the filename and used the webdav
saver, it replaced the space with the URL encoding (%20) in the filename on
save.
This was tested using my Apache setup from Safari on iOS. Haven't tested
other browsers but I doubt they will be any different.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/7267242b-b825-453b-b575-5041f655543a%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/6779a5e4-eabd-4c02-b1fe-e3283d47842a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
@TiddlyTweeter
2017-08-31 14:10:47 UTC
Reply
Permalink
Raw Message
Double encoding issue? Is it an infinite regress?
Post by Lost Admin
"space test.html" got saved as "space%20test.html" which got saved as
"space%2520test.html" which got re-loaded as "space%252520.test.html", so
the %20 encoding doesn't really play nice.
It works but you have to constantly mess with the address when saving. I
would say replacing spaces with underscores in your filenames would be less
painful.
Post by Arlen Beiler
And can you reload the renamed file and continue saving to it? Or not?
Post by Lost Admin
When I created a wiki with a space in the filename and used the webdav
saver, it replaced the space with the URL encoding (%20) in the filename on
save.
This was tested using my Apache setup from Safari on iOS. Haven't tested
other browsers but I doubt they will be any different.
--
You received this message because you are subscribed to the Google
Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/7267242b-b825-453b-b575-5041f655543a%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/8ab257a7-14b3-4e98-804c-302e8f85f440%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
PMario
2017-08-30 17:51:03 UTC
Reply
Permalink
Raw Message
Hi foks,

I just did a proof of concept using IIS with WebDAV on windows 10 pro. ..
It seems to work out of the box, with IE-11, Edge, FF55 and FF57-nightly.

I will record a short video, so everyone interested, should be able to get
it going. ... There is a little issue, with the TW default saver, but it
should be streight forward to fix it.

have fun!
mario
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/526924ad-45ce-45f7-9977-6401d41aa49b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
'Mark S.' via TiddlyWiki
2017-08-30 18:52:06 UTC
Reply
Permalink
Raw Message
What would the performance and safety concerns be for running IIS/WebDav on
a semi-permanent basis? If you forward the ports (and know your IP) can you
access your files outside of the home?

Mark
Post by PMario
Hi foks,
I just did a proof of concept using IIS with WebDAV on windows 10 pro. ..
It seems to work out of the box, with IE-11, Edge, FF55 and FF57-nightly.
I will record a short video, so everyone interested, should be able to get
it going. ... There is a little issue, with the TW default saver, but it
should be streight forward to fix it.
have fun!
mario
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/33323c93-8f90-4c98-aaa4-856cc0b2f7ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-08-31 13:12:10 UTC
Reply
Permalink
Raw Message
Safety/security concerns with WebDav:

WebDav is conceptually a share network folder (so much so you can mount
them with a drive letter on Windows) that is provided over HTTP. This means
anyone who can access the webdav url can read, write, and delete to all the
files available there. This includes making new directories.

To protect it, one typically uses HTTP Basic (or Digest) Authentication
(part of the web server set-up). With basic authentication that means the
password (and user name) are going across the network (including Internet
when doing so remotely) encrypted and anyone who sees the traffic can read
the login credentials. Using digest authentication reduces this risk as the
password is not longer sent across the network. Usually it is recommended
that you use HTTPS for webdav and not allow HTTP (unencrypted) connections.
However, SSL/TLS has a lot of insecure configurations, so you need to know
what you are doing (and what encryption protocols to allow).

Also, all the files that are stored on your hard drive for use with webdav
need to be owned by the system use that the web server is running as. This
makes it easy for a hacker who manages to breach your web server to mess
with those files (website defacement happens because of this sort of thing).

Of course, several cloud providers do feel that they can sufficiently
secure webdav and offer it as part of their service. box.com offers webdav
access. Under the covers MS SharePoint (and therefore OneDrive) use webdav.

My home system has webdav exposed to the Internet (https only, basic
authentication). my Wiki.suntrap.ca site also has webdav enabled.

If you are setting this up on your home PC for access from the Internet
(with port forwarding), I strongly suggest setting it up with SSL/TLS and
using digest authentication. Also, set-up a system account (not your user
account and not the windows "system" account) specifically to run the
webdav server. Also, keep an eye on the space that is being used on your
hard drive by that account (a hacker who manages to get access may try to
adjust it to set-up a "warez server").

The above was all the scary stuff, here are some of the advantages:

If you are running Windows or Apple OS X, you can mount a webdav like a
network drive and save any files there you want (not just tiddlywiki).

If you know how to configure your web server, you can set up public
directories that don't require authentication to read but do require
authentication to write files. You can also set-up private directories that
require authentication for all access to files (in theory you could set up
a blind drop where people can send you files without authenticating but not
read them, although this is probably a bad idea).

You can pretty easily create multiple account so people can share files.
It's a bit more complicated to give per-person private directories.

If you are extremely paranoid, you can set-up SSL/TLS client authentication
which would require the browser to have a specific certificate (similar to
the way the server needs one for HTTPS).

You could set-up your own carddav (address book) or caldav (calendar)
server.
Post by 'Mark S.' via TiddlyWiki
What would the performance and safety concerns be for running IIS/WebDav
on a semi-permanent basis? If you forward the ports (and know your IP) can
you access your files outside of the home?
Mark
Post by PMario
Hi foks,
I just did a proof of concept using IIS with WebDAV on windows 10 pro. ..
It seems to work out of the box, with IE-11, Edge, FF55 and FF57-nightly.
I will record a short video, so everyone interested, should be able to
get it going. ... There is a little issue, with the TW default saver, but
it should be streight forward to fix it.
have fun!
mario
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/41dbe85c-6922-4032-83db-db61e77aff48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
PMario
2017-08-31 16:44:51 UTC
Reply
Permalink
Raw Message
Well written!
Post by Lost Admin
WebDav is conceptually a share network folder (so much so you can mount
them with a drive letter on Windows) that is provided over HTTP. This means
anyone who can access the webdav url can read, write, and delete to all the
files available there. This includes making new directories.
Somewhere I read, that starting with IIS-7 write commands have to use
basic-auth as minimal requirement.
Post by Lost Admin
To protect it, one typically uses HTTP Basic (or Digest) Authentication
(part of the web server set-up). With basic authentication that means the
password (and user name) are going across the network (including Internet
when doing so remotely) in clear text and anyone who sees the traffic can
read the login credentials. Using digest authentication reduces this risk
as the password is no longer sent across the network. Usually it is
recommended that you use HTTPS for webdav and not allow HTTP (unencrypted)
connections. However, SSL/TLS has a lot of insecure configurations, so you
need to know what you are doing (and what encryption protocols to allow).
Therefore IMO you have to use HTTPS as a minimal requrement if you face the
internet.

... snip ...
Post by Lost Admin
If you are extremely paranoid, you can set-up SSL/TLS client
authentication which would require the browser to have a specific
certificate (similar to the way the server needs one for HTTPS).
IMO no need to be extreamly paranoid. .. It's just a very convenient and
secure workflow, once you could manage the certificate deployment.

You could set-up your own carddav (address book) or caldav (calendar)
Post by Lost Admin
server.
That's a nice plus

have fun!
mario
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/5179e9bb-ca5b-4916-9050-3c6b5ef9a8a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
PMario
2017-08-31 17:02:42 UTC
Reply
Permalink
Raw Message
Post by 'Mark S.' via TiddlyWiki
What would the performance and safety concerns be for running IIS/WebDav
on a semi-permanent basis? If you forward the ports (and know your IP) can
you access your files outside of the home?
As Lost Admin points out. If you want to open up the internet, it gets a
bit more tricky. The complexity raises quite a bit :)

There's a reason, why I wrote:

I'm basically interested in a replacement for TiddlyFox and not in a
Post by 'Mark S.' via TiddlyWiki
"internet facing" setup. ...
I knew, that those questions are coming. I want to show what's possible
"out of the box", with built in windows components, that should be
available for many users.

FF57 produces some headaches. ... The setting I'm imagine should work with
every browser, without any addOns. ...

In my first post I also did point out, that M$ limits the possibilities
quite a bit. see: 2.b-(iii) in win10 user terms
<https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/UseTerms_Retail_Windows_10_English.htm>.
So for me it was clear, to use the stuff in a small intranet setting only.
For real projects I'd go with an open source setting as introduced by Lost
Admin. ...

... I didn't have a look, what IIS licenses would cost for real world
projects. ... Probably no problem for companies, but way to heavy for
personal use.

have fun!
mario
PS: Since I have an english Win10 VM now, I can start to record the stuff.
... to be continued ...
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/34da7ccd-5c27-4ad7-b882-36d47f2dfc80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
PMario
2017-09-01 15:05:42 UTC
Reply
Permalink
Raw Message
Hi,

See this topic for the videos:
https://groups.google.com/forum/#!topic/tiddlywiki/_YwmiKqMyrI

have fun!
mario
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/57153ed8-bdf6-43b6-99ac-46226de9916e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
TonyM
2017-09-06 00:34:30 UTC
Reply
Permalink
Raw Message
Folks,

I just want to report I am using IIS WebDav Implementation to access a TW5
and whilst it seems to work most of the time the tab it was in has
mysteriously disappeared from firefox and I cant return to the wiki (even
in another browser) and avoid the 412? error until I reboot my computer.

When I next have time to reproduce the problem which sounds related to the
Apache errors discussed below I can post in more detail.

Regards
Tony
Post by PMario
Hi LostAdmin,
That's a perfect reminder, to have a closer look at MS built-in stuff.
WebDav is part of* Internet Information Services (IIS)*, which seems to
be available for up to 20 users for Windows Vista, 7, 8.x and 10. ...
I'm basically interested in a replacement for TiddlyFox and not in a
"internet facing" setup. ...
from win10 user terms
<https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/UseTerms_Retail_Windows_10_English.htm>.
*2. Installation and Use Rights.*
*<snip>*
*d. Multi use scenarios.*
<snip>
(iii) *Device connections*. You may allow up to 20 other devices to
access the software installed on the licensed device for the purpose of
using the following software features: file services, print services, Internet
information services, and Internet connection sharing and telephony
services on the licensed device. You may allow any number of devices to
access the software on the licensed device to synchronize data between
devices. This section does not mean, however, that you have the right to
install the software, or use the primary function of the software (other
than the features listed in this section), on any of these other devices.
So with the right settings, it *may be* possible to activate it for most
windows machines. ... The important phrase is "may be", since nobody really
knows, how crippeld "Home xxx" and OEM Licenses really are.
For those who are courious, *IIS *is the equivalent of the Apache and
Lighttdp servers, that Lost Admin mentioned. ... So it should be possible
to use the stuff for local installations.
... I'm not at home at the moment. So I can't run tests with my machine.
But anyone who is interested, should expolore the docs
<https://docs.microsoft.com/en-us/iis/install/installing-publishing-technologies/installing-and-configuring-webdav-on-iis>,
run some tests and report back here.
Especially interesting: OS version used! So we can see, if it works with
"Home xxxx" licenses. I do have a Win10 Pro, wich I can test on :)
have fun!
mario
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/b22f3197-e674-482f-9511-4e98396c83f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-09-01 13:22:09 UTC
Reply
Permalink
Raw Message
Is there an easy way to get TiddlyWiki to re-read itself after saving?

Apache tracks the time that you read the file and issues an error if you
try to save back to the server if the file on disk has a newer timestamp.
Which means: after I save changes to a file, it give me an error on
subsequent changes unless I reload the wiki.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Arlen Beiler
2017-09-01 13:47:01 UTC
Reply
Permalink
Raw Message
I remember running into that when writing TiddlyServer. The apache
webdav module should return some kind of revision string. The put saver
expects an Etag, but this may not necessarily be what Apache sends.
However, I believe that is where the problem is.
Post by Lost Admin
Is there an easy way to get TiddlyWiki to re-read itself after saving?
Apache tracks the time that you read the file and issues an error if you
try to save back to the server if the file on disk has a newer timestamp.
Which means: after I save changes to a file, it give me an error on
subsequent changes unless I reload the wiki.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/
msgid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSQTWW_%3DsN2M9QRc-2weNLRTbwXaH8ZHKeeDTrUNzh%3DgQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-09-01 14:11:49 UTC
Reply
Permalink
Raw Message
Ah! you are ahead of me in figuring out what needs to be done.
Unfortunately, my javascript skills are nowhere near good enough to figure
out how to integrate the Apache way of doing things into TiddlyWiki.
Post by Arlen Beiler
I remember running into that when writing TiddlyServer. The apache
webdav module should return some kind of revision string. The put saver
expects an Etag, but this may not necessarily be what Apache sends.
However, I believe that is where the problem is.
Post by Lost Admin
Is there an easy way to get TiddlyWiki to re-read itself after saving?
Apache tracks the time that you read the file and issues an error if you
try to save back to the server if the file on disk has a newer timestamp.
Which means: after I save changes to a file, it give me an error on
subsequent changes unless I reload the wiki.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/f2c207bb-f3de-44d6-9954-f5ad9bd0361c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Arlen Beiler
2017-09-01 14:25:39 UTC
Reply
Permalink
Raw Message
Ok, well all I need is the request and response info for the put request.
Actually, just the response headers. If you open your Developer Tools and
go to the network tab, it will show you all the requests the page makes for
everything. Find the put request it sends to save the file and click on it.
It should show you the response headers. You can copy it here or email it
to me directly if you like.
Post by Lost Admin
Ah! you are ahead of me in figuring out what needs to be done.
Unfortunately, my javascript skills are nowhere near good enough to figure
out how to integrate the Apache way of doing things into TiddlyWiki.
Post by Arlen Beiler
I remember running into that when writing TiddlyServer. The apache
webdav module should return some kind of revision string. The put saver
expects an Etag, but this may not necessarily be what Apache sends.
However, I believe that is where the problem is.
Post by Lost Admin
Is there an easy way to get TiddlyWiki to re-read itself after saving?
Apache tracks the time that you read the file and issues an error if you
try to save back to the server if the file on disk has a newer timestamp.
Which means: after I save changes to a file, it give me an error on
subsequent changes unless I reload the wiki.
--
You received this message because you are subscribed to the Google
Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/ms
gid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/
msgid/tiddlywiki/f2c207bb-f3de-44d6-9954-f5ad9bd0361c%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/f2c207bb-f3de-44d6-9954-f5ad9bd0361c%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSQ9kPt01E%3D5OiEADQYQjW6cB3xJ5RXNN0meNYcQpMz5dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-09-02 17:29:24 UTC
Reply
Permalink
Raw Message
Here you go ... This only covers the save, including the authentication
step (minus credentials)


*Initial PUT http://domain.dom/index.htmlStatus code: 404*

Response headers (296 B)
Date
Sat, 02 Sep 2017 17:19:45 GMT
Server
Apache/2.4.27 (FreeBSD) OpenSSL/1.0.1s-freebsd PHP/5.6.31
Keep-Alive
timeout=5, max=99
Connection
Keep-Alive
Content-Type
text/html
Request headers (452 B)
Host
domain.dom
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013328
DNT
1
Connection
keep-alive



*PUT http://domain.dom/index.htmlStatus Code: 204Version HTTP/1.1*

Request headers (499 B)
Host
ariel.suntrap.ca
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013328
DNT
1
Connection
keep-alive
Authorization
Basic <redacted>

*Now save again without reloading*


*PUT http://domain.dom/index.htmlStatus Code: 412 Precondition Failed*
Response headers (262 B)
Date
Sat, 02 Sep 2017 17:27:15 GMT
Server
Apache/2.4.27 (FreeBSD) OpenSSL/1.0.1s-freebsd PHP/5.6.31
Content-Length
249
Keep-Alive
timeout=5, max=100
Connection
Keep-Alive
Content-Type
text/html; charset=iso-8859-1
Request headers (499 B)
Host
domain.dom
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013314
DNT
1
Authorization
Basic <redacted>
Connection
keep-alive
Post by Arlen Beiler
Ok, well all I need is the request and response info for the put request.
Actually, just the response headers. If you open your Developer Tools and
go to the network tab, it will show you all the requests the page makes for
everything. Find the put request it sends to save the file and click on it.
It should show you the response headers. You can copy it here or email it
to me directly if you like.
Post by Lost Admin
Ah! you are ahead of me in figuring out what needs to be done.
Unfortunately, my javascript skills are nowhere near good enough to figure
out how to integrate the Apache way of doing things into TiddlyWiki.
Post by Arlen Beiler
I remember running into that when writing TiddlyServer. The apache
webdav module should return some kind of revision string. The put saver
expects an Etag, but this may not necessarily be what Apache sends.
However, I believe that is where the problem is.
Post by Lost Admin
Is there an easy way to get TiddlyWiki to re-read itself after saving?
Apache tracks the time that you read the file and issues an error if
you try to save back to the server if the file on disk has a newer
timestamp. Which means: after I save changes to a file, it give me an error
on subsequent changes unless I reload the wiki.
--
You received this message because you are subscribed to the Google
Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/f2c207bb-f3de-44d6-9954-f5ad9bd0361c%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/f2c207bb-f3de-44d6-9954-f5ad9bd0361c%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/ae7f53cc-1797-4a21-ae58-4c0c34437e79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Arlen Beiler
2017-09-02 17:58:06 UTC
Reply
Permalink
Raw Message
Good afternoon,
What is the response headers for the request with the status code 204? And
why does the initial put request have a status of 404?
Thanks

On Sep 2, 2017 1:29 PM, "Lost Admin" <***@gmail.com> wrote:

Here you go ... This only covers the save, including the authentication
step (minus credentials)


*Initial PUT http://domain.dom/index.html
<http://domain.dom/index.html>Status code: 404*

Response headers (296 B)
Date
Sat, 02 Sep 2017 17:19:45 GMT
Server
Apache/2.4.27 (FreeBSD) OpenSSL/1.0.1s-freebsd PHP/5.6.31
Keep-Alive
timeout=5, max=99
Connection
Keep-Alive
Content-Type
text/html
Request headers (452 B)
Host
domain.dom
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013328
DNT
1
Connection
keep-alive



*PUT http://domain.dom/index.html <http://domain.dom/index.html>Status
Code: 204Version HTTP/1.1*

Request headers (499 B)
Host
ariel.suntrap.ca
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013328
DNT
1
Connection
keep-alive
Authorization
Basic <redacted>

*Now save again without reloading*


*PUT http://domain.dom/index.html <http://domain.dom/index.html>Status
Code: 412 Precondition Failed*
Response headers (262 B)
Date
Sat, 02 Sep 2017 17:27:15 GMT
Server
Apache/2.4.27 (FreeBSD) OpenSSL/1.0.1s-freebsd PHP/5.6.31
Content-Length
249
Keep-Alive
timeout=5, max=100
Connection
Keep-Alive
Content-Type
text/html; charset=iso-8859-1
Request headers (499 B)
Host
domain.dom
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013314
DNT
1
Authorization
Basic <redacted>
Connection
keep-alive
Post by Arlen Beiler
Ok, well all I need is the request and response info for the put request.
Actually, just the response headers. If you open your Developer Tools and
go to the network tab, it will show you all the requests the page makes for
everything. Find the put request it sends to save the file and click on it.
It should show you the response headers. You can copy it here or email it
to me directly if you like.
Post by Lost Admin
Ah! you are ahead of me in figuring out what needs to be done.
Unfortunately, my javascript skills are nowhere near good enough to figure
out how to integrate the Apache way of doing things into TiddlyWiki.
Post by Arlen Beiler
I remember running into that when writing TiddlyServer. The apache
webdav module should return some kind of revision string. The put saver
expects an Etag, but this may not necessarily be what Apache sends.
However, I believe that is where the problem is.
Post by Lost Admin
Is there an easy way to get TiddlyWiki to re-read itself after saving?
Apache tracks the time that you read the file and issues an error if
you try to save back to the server if the file on disk has a newer
timestamp. Which means: after I save changes to a file, it give me an error
on subsequent changes unless I reload the wiki.
--
You received this message because you are subscribed to the Google
Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/ms
gid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/ms
gid/tiddlywiki/f2c207bb-f3de-44d6-9954-f5ad9bd0361c%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/f2c207bb-f3de-44d6-9954-f5ad9bd0361c%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/
msgid/tiddlywiki/ae7f53cc-1797-4a21-ae58-4c0c34437e79%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/ae7f53cc-1797-4a21-ae58-4c0c34437e79%40googlegroups.com?utm_medium=email&utm_source=footer>
.

For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSS7_nBbA5BVJZ%2BiQZ8krF%2BFOKw6x3prJFz-8Y1ux_b%3DOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-09-02 18:51:17 UTC
Reply
Permalink
Raw Message
I think the 404 was a mis-type on my part and should have been 401
(unauthorized). As this was the first attempt to "save" I had not yet
authenticated.

Re-doing my testing, the 204 is as follows (this is the successful save of
Post by Arlen Beiler
Good afternoon,
What is the response headers for the request with the status code 204? And
why does the initial put request have a status of 404?
Thanks
Here you go ... This only covers the save, including the authentication
step (minus credentials)
*Initial PUT http://domain.dom/index.html
<http://domain.dom/index.html>Status code: 404*
Response headers (296 B)
Date
Sat, 02 Sep 2017 17:19:45 GMT
Server
Apache/2.4.27 (FreeBSD) OpenSSL/1.0.1s-freebsd PHP/5.6.31
Keep-Alive
timeout=5, max=99
Connection
Keep-Alive
Content-Type
text/html
Request headers (452 B)
Host
domain.dom
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013328
DNT
1
Connection
keep-alive
*PUT http://domain.dom/index.html <http://domain.dom/index.html>Status
Code: 204Version HTTP/1.1*
Request headers (499 B)
Host
ariel.suntrap.ca
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013328
DNT
1
Connection
keep-alive
Authorization
Basic <redacted>
*Now save again without reloading*
*PUT http://domain.dom/index.html <http://domain.dom/index.html>Status
Code: 412 Precondition Failed*
Response headers (262 B)
Date
Sat, 02 Sep 2017 17:27:15 GMT
Server
Apache/2.4.27 (FreeBSD) OpenSSL/1.0.1s-freebsd PHP/5.6.31
Content-Length
249
Keep-Alive
timeout=5, max=100
Connection
Keep-Alive
Content-Type
text/html; charset=iso-8859-1
Request headers (499 B)
Host
domain.dom
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013314
DNT
1
Authorization
Basic <redacted>
Connection
keep-alive
Post by Arlen Beiler
Ok, well all I need is the request and response info for the put request.
Actually, just the response headers. If you open your Developer Tools and
go to the network tab, it will show you all the requests the page makes for
everything. Find the put request it sends to save the file and click on it.
It should show you the response headers. You can copy it here or email it
to me directly if you like.
Post by Lost Admin
Ah! you are ahead of me in figuring out what needs to be done.
Unfortunately, my javascript skills are nowhere near good enough to figure
out how to integrate the Apache way of doing things into TiddlyWiki.
Post by Arlen Beiler
I remember running into that when writing TiddlyServer. The apache
webdav module should return some kind of revision string. The put saver
expects an Etag, but this may not necessarily be what Apache sends.
However, I believe that is where the problem is.
Post by Lost Admin
Is there an easy way to get TiddlyWiki to re-read itself after saving?
Apache tracks the time that you read the file and issues an error if
you try to save back to the server if the file on disk has a newer
timestamp. Which means: after I save changes to a file, it give me an error
on subsequent changes unless I reload the wiki.
--
You received this message because you are subscribed to the Google
Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/f2c207bb-f3de-44d6-9954-f5ad9bd0361c%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/f2c207bb-f3de-44d6-9954-f5ad9bd0361c%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/ae7f53cc-1797-4a21-ae58-4c0c34437e79%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/ae7f53cc-1797-4a21-ae58-4c0c34437e79%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/44825365-1645-45d8-beb1-47b7882428e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Arlen Beiler
2017-09-02 19:24:21 UTC
Reply
Permalink
Raw Message
Interesting. Could you also post the request and response for the initial
get request for the file? This format works perfect.

On Sep 2, 2017 14:51, "Lost Admin" <***@gmail.com> wrote:

I think the 404 was a mis-type on my part and should have been 401
(unauthorized). As this was the first attempt to "save" I had not yet
authenticated.

Re-doing my testing, the 204 is as follows (this is the successful save of
Post by Arlen Beiler
Good afternoon,
What is the response headers for the request with the status code 204? And
why does the initial put request have a status of 404?
Thanks
Here you go ... This only covers the save, including the authentication
step (minus credentials)
*Initial PUT http://domain.dom/index.html
<http://domain.dom/index.html>Status code: 404*
Response headers (296 B)
Date
Sat, 02 Sep 2017 17:19:45 GMT
Server
Apache/2.4.27 (FreeBSD) OpenSSL/1.0.1s-freebsd PHP/5.6.31
Keep-Alive
timeout=5, max=99
Connection
Keep-Alive
Content-Type
text/html
Request headers (452 B)
Host
domain.dom
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013328
DNT
1
Connection
keep-alive
*PUT http://domain.dom/index.html <http://domain.dom/index.html>Status
Code: 204Version HTTP/1.1*
Request headers (499 B)
Host
ariel.suntrap.ca
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013328
DNT
1
Connection
keep-alive
Authorization
Basic <redacted>
*Now save again without reloading*
*PUT http://domain.dom/index.html <http://domain.dom/index.html>Status
Code: 412 Precondition Failed*
Response headers (262 B)
Date
Sat, 02 Sep 2017 17:27:15 GMT
Server
Apache/2.4.27 (FreeBSD) OpenSSL/1.0.1s-freebsd PHP/5.6.31
Content-Length
249
Keep-Alive
timeout=5, max=100
Connection
Keep-Alive
Content-Type
text/html; charset=iso-8859-1
Request headers (499 B)
Host
domain.dom
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013314
DNT
1
Authorization
Basic <redacted>
Connection
keep-alive
Post by Arlen Beiler
Ok, well all I need is the request and response info for the put request.
Actually, just the response headers. If you open your Developer Tools and
go to the network tab, it will show you all the requests the page makes for
everything. Find the put request it sends to save the file and click on it.
It should show you the response headers. You can copy it here or email it
to me directly if you like.
Post by Lost Admin
Ah! you are ahead of me in figuring out what needs to be done.
Unfortunately, my javascript skills are nowhere near good enough to figure
out how to integrate the Apache way of doing things into TiddlyWiki.
Post by Arlen Beiler
I remember running into that when writing TiddlyServer. The apache
webdav module should return some kind of revision string. The put saver
expects an Etag, but this may not necessarily be what Apache sends.
However, I believe that is where the problem is.
Post by Lost Admin
Is there an easy way to get TiddlyWiki to re-read itself after saving?
Apache tracks the time that you read the file and issues an error if
you try to save back to the server if the file on disk has a newer
timestamp. Which means: after I save changes to a file, it give me an error
on subsequent changes unless I reload the wiki.
--
You received this message because you are subscribed to the Google
Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/9084db99-3deb-
446a-a6e3-d205ddc5269e%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/ms
gid/tiddlywiki/f2c207bb-f3de-44d6-9954-f5ad9bd0361c%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/f2c207bb-f3de-44d6-9954-f5ad9bd0361c%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/ms
gid/tiddlywiki/ae7f53cc-1797-4a21-ae58-4c0c34437e79%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/ae7f53cc-1797-4a21-ae58-4c0c34437e79%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/
msgid/tiddlywiki/44825365-1645-45d8-beb1-47b7882428e5%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/44825365-1645-45d8-beb1-47b7882428e5%40googlegroups.com?utm_medium=email&utm_source=footer>
.

For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSTGWBuvXq%2B9un8gHeBO1WuupaW0GCWsvF8RGW42hsBJ_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-09-03 16:47:24 UTC
Reply
Permalink
Raw Message
I put the whole sequence of steps from intial GET request through the
succeeding and failing PUT requests here
https://wiki.suntrap.ca/davsaver.html I figure this would be easier to
refer to while analyzing.
Post by Arlen Beiler
Interesting. Could you also post the request and response for the initial
get request for the file? This format works perfect.
I think the 404 was a mis-type on my part and should have been 401
(unauthorized). As this was the first attempt to "save" I had not yet
authenticated.
Re-doing my testing, the 204 is as follows (this is the successful save of
Post by Arlen Beiler
Good afternoon,
What is the response headers for the request with the status code 204?
And why does the initial put request have a status of 404?
Thanks
Here you go ... This only covers the save, including the authentication
step (minus credentials)
*Initial PUT http://domain.dom/index.html
<http://domain.dom/index.html>Status code: 404*
Response headers (296 B)
Date
Sat, 02 Sep 2017 17:19:45 GMT
Server
Apache/2.4.27 (FreeBSD) OpenSSL/1.0.1s-freebsd PHP/5.6.31
Keep-Alive
timeout=5, max=99
Connection
Keep-Alive
Content-Type
text/html
Request headers (452 B)
Host
domain.dom
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013328
DNT
1
Connection
keep-alive
*PUT http://domain.dom/index.html <http://domain.dom/index.html>Status
Code: 204Version HTTP/1.1*
Request headers (499 B)
Host
ariel.suntrap.ca
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013328
DNT
1
Connection
keep-alive
Authorization
Basic <redacted>
*Now save again without reloading*
*PUT http://domain.dom/index.html <http://domain.dom/index.html>Status
Code: 412 Precondition Failed*
Response headers (262 B)
Date
Sat, 02 Sep 2017 17:27:15 GMT
Server
Apache/2.4.27 (FreeBSD) OpenSSL/1.0.1s-freebsd PHP/5.6.31
Content-Length
249
Keep-Alive
timeout=5, max=100
Connection
Keep-Alive
Content-Type
text/html; charset=iso-8859-1
Request headers (499 B)
Host
domain.dom
User-Agent
Mozilla/5.0 (Windows NT 10.0; 
) Gecko/20100101 Firefox/55.0
Accept
*/*
Accept-Language
en-US,en;q=0.5
Accept-Encoding
gzip, deflate
Referer
http://domain.dom/index.html
Content-Type
text/html;charset=UTF-8, appli
orm-urlencoded; charset=UTF-8
If-Match
"1eb890-5582095dd9986"
Content-Length
2013314
DNT
1
Authorization
Basic <redacted>
Connection
keep-alive
Post by Arlen Beiler
Ok, well all I need is the request and response info for the put
request. Actually, just the response headers. If you open your Developer
Tools and go to the network tab, it will show you all the requests the page
makes for everything. Find the put request it sends to save the file and
click on it. It should show you the response headers. You can copy it here
or email it to me directly if you like.
Post by Lost Admin
Ah! you are ahead of me in figuring out what needs to be done.
Unfortunately, my javascript skills are nowhere near good enough to figure
out how to integrate the Apache way of doing things into TiddlyWiki.
Post by Arlen Beiler
I remember running into that when writing TiddlyServer. The apache
webdav module should return some kind of revision string. The put saver
expects an Etag, but this may not necessarily be what Apache sends.
However, I believe that is where the problem is.
Post by Lost Admin
Is there an easy way to get TiddlyWiki to re-read itself after saving?
Apache tracks the time that you read the file and issues an error if
you try to save back to the server if the file on disk has a newer
timestamp. Which means: after I save changes to a file, it give me an error
on subsequent changes unless I reload the wiki.
--
You received this message because you are subscribed to the Google
Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it,
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/9084db99-3deb-446a-a6e3-d205ddc5269e%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/f2c207bb-f3de-44d6-9954-f5ad9bd0361c%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/f2c207bb-f3de-44d6-9954-f5ad9bd0361c%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/ae7f53cc-1797-4a21-ae58-4c0c34437e79%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/ae7f53cc-1797-4a21-ae58-4c0c34437e79%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/44825365-1645-45d8-beb1-47b7882428e5%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/44825365-1645-45d8-beb1-47b7882428e5%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/609c0389-6fa1-44f1-8d2a-85de19e43b8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Arlen Beiler
2017-09-05 13:17:29 UTC
Reply
Permalink
Raw Message
It is becoming pretty clear that for some reason the Etag is not being set
in the response header, nor anything else equivalent to it. Per our
discussion privately, it does seem that this is an Apache issue, however I
have not been able to look into it further.

A couple of articles which touch on this:

- https://fullstackhack.wordpress.com/2014/12/10/the-
pain-of-etags-mod_deflate-apache-2-4-and-tomcat-7/
<https://fullstackhack.wordpress.com/2014/12/10/the-pain-of-etags-mod_deflate-apache-2-4-and-tomcat-7/>

- https://httpd.apache.org/docs/2.4/caching.html

At some point I will test it on one of my servers and see if I can get it
working. However, it is obvious that this is the problem. One option would
be to make a second head request if the 204 response does not contain an
Etag, but I guess that wouldn't be atomic either.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSSKxwo4OqO5Z127uob_JKaWsT69ibBXyvc6s92fvT72hg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-09-05 13:46:49 UTC
Reply
Permalink
Raw Message
I was coming to the same conclusion, except it appears that IIS has the
same problem (judging by what was going on in the IIS WebDAV setup video
thread).

Also, if I read the technical docs on Etag, the PUT shouldn't send a new
Etag as there is no content in the response (the Etag is tied to the reply
content).

It looks like the HEAD call does include an Etag, so conceivably issuing a
HEAD after confirming the PUT succeeded would get the new Etag.
Unfortunately, that would introduce a race condition if there are multiple
people editing the file.


Does the TiddlyWiki WebDAV saver support anything other than Etag? While it
appears Etag is the default, I ran across some cryptic comments about
disabling Etag and adding a last-changed timestamp. Possibly the PUT would
include the timestamp. Unfortunately, this is not the default for Apache
and would require clear documentation on our part to explain to people how
to set-up their WebDAV servers (and significantly reduces the likelihood
that WebDAV supporting cloud providers will work properly).

I've been looking but haven't (yet) figured out how to tell Apache to
include the Etag header in the PUT response header.


NOTE: to those who have no idea what I was talking about above, Arlen and I
are digging into the finer points of the HTTP protocol and WebDAV protocol
to see if we can fix an issue that's been bugging us (well, at least me).
Post by Arlen Beiler
It is becoming pretty clear that for some reason the Etag is not being set
in the response header, nor anything else equivalent to it. Per our
discussion privately, it does seem that this is an Apache issue, however I
have not been able to look into it further.
-
https://fullstackhack.wordpress.com/2014/12/10/the-pain-of-etags-mod_deflate-apache-2-4-and-tomcat-7/
- https://httpd.apache.org/docs/2.4/caching.html
At some point I will test it on one of my servers and see if I can get it
working. However, it is obvious that this is the problem. One option would
be to make a second head request if the 204 response does not contain an
Etag, but I guess that wouldn't be atomic either.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/f6fb9358-ef37-419d-882a-71724c99b415%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
PMario
2017-09-05 17:12:06 UTC
Reply
Permalink
Raw Message
Post by Lost Admin
I was coming to the same conclusion, except it appears that IIS has the
same problem (judging by what was going on in the IIS WebDAV setup video
thread).
Is there a minimal test-case? So I can reproduce the issue?
Post by Lost Admin
It looks like the HEAD call does include an Etag, so conceivably issuing a
HEAD after confirming the PUT succeeded would get the new Etag.
Unfortunately, that would introduce a race condition if there are multiple
Post by Lost Admin
people editing the file.
WebDAV supports a locking mechanism. ... It could be used to prevent 2
users editing a TW at the same time.

-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/f70dfc34-0b51-4edf-a0ce-6eec63876a22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
@TiddlyTweeter
2017-09-05 17:16:54 UTC
Reply
Permalink
Raw Message
I am absolutely loving this thread. Its so technical it could be an opera
in Latvian.

Carry on. I'm just making notes.

Best wishes
Josiah
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/0999eeeb-c280-4a34-ac39-efa9c01cb30c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-09-05 17:21:04 UTC
Reply
Permalink
Raw Message
Minimal, and reliable test case:

1) Set-up a WebDAV server on Apache (follow the Apache instructions,
nothing special).

2) Put a TiddlyWiki on it. Also nothing special, just the standard
empty.html from TiddlyWiki.com.

3) Edit a Tiddler and save it (make sure it saves to the WebDAV server.

4) Wait for the save to finish.

5) Make another edit (of the same tiddler if you want)

6) Save again.

7) The error pops up.


In Firefox the developer tools can be used to see what is passing on the
network. Pay close attention to the ETAG header and it's value (and when it
doesn't show up). In theory you could do this with Chrome too, but when I
try the Chrome developer tools keep hanging so I can't see the headers on
each step.


Judging by what is going on in the IIS thread, I think IIS has the same
issue.

On my Lighttpd server, I don't have this issue.
Post by PMario
Post by Lost Admin
I was coming to the same conclusion, except it appears that IIS has the
same problem (judging by what was going on in the IIS WebDAV setup video
thread).
Is there a minimal test-case? So I can reproduce the issue?
Post by Lost Admin
It looks like the HEAD call does include an Etag, so conceivably issuing
a HEAD after confirming the PUT succeeded would get the new Etag.
Unfortunately, that would introduce a race condition if there are multiple
Post by Lost Admin
people editing the file.
WebDAV supports a locking mechanism. ... It could be used to prevent 2
users editing a TW at the same time.
Yes, that is sort of the problem. the mechanism to prevent the editing
conflicts is handled by the ETAG header. But, when you save changes (HTTP
PUT), you don't get a new ETAG with the response from Apache. However, the
ETAG changes whenever the file changes. At least, I *think* that is what is
going on.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/1ebffb7b-86a0-4b39-9172-f562bd559091%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Arlen Beiler
2017-09-05 20:41:29 UTC
Reply
Permalink
Raw Message
I just thought I would mention that TiddlyServer does not have this problem
either. I specifically designed it to support the current webdav (put)
saver in TiddlyWiki.

Judging by what is going on in the IIS thread, I think IIS has the same
issue.

On my Lighttpd server, I don't have this issue.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSQ9o0%2BKougbT1RjJQOY88cEuGdT4b_WOV5EFWDdf80J0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-09-05 21:50:05 UTC
Reply
Permalink
Raw Message
That is useful when running it on your local computer, but how robust is it
if you drop it on the Internet?

There are so many configuration settings in Apache, there must be a way to
tell it to include an ETag header in PUT requests.
Post by Arlen Beiler
I just thought I would mention that TiddlyServer does not have this
problem either. I specifically designed it to support the current webdav
(put) saver in TiddlyWiki.
Judging by what is going on in the IIS thread, I think IIS has the same
issue.
On my Lighttpd server, I don't have this issue.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/1f0e01a4-1897-4791-a89a-09b36363551a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Arlen Beiler
2017-09-06 02:09:47 UTC
Reply
Permalink
Raw Message
It has basic auth, but that's it. So it really isn't. However, I would
welcome your input on all this as it is probably where I should focus next.
This is a good point.
Post by Lost Admin
That is useful when running it on your local computer, but how robust is
it if you drop it on the Internet?
Post by Arlen Beiler
I just thought I would mention that TiddlyServer does not have this
problem either. I specifically designed it to support the current webdav
(put) saver in TiddlyWiki.
Judging by what is going on in the IIS thread, I think IIS has the same
issue.
On my Lighttpd server, I don't have this issue.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSRTFyMnDAUHcUkRm114TXZcmAzaW-kRwgpZqg6UX8Gdgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-09-05 21:48:20 UTC
Reply
Permalink
Raw Message
Post by Lost Admin
...
On my Lighttpd server, I don't have this issue.
...
I've tested using Firefox and put screenshots up at
https://wiki.suntrap.ca/webdav/davsaver.html (for now). Lighttpd does not
exhibit this issue but it also doesn't send the If-Match: header on then
2nd PUT request (the one that fails with Apache and maybe IIS).
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/c10a85d1-e570-4959-87b1-050542d2fc55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
PMario
2017-09-06 13:57:56 UTC
Reply
Permalink
Raw Message
Post by Lost Admin
1) Set-up a WebDAV server on Apache (follow the Apache instructions,
nothing special).
:) .. I was thinking about a IIS testcase. .. Will run some tests

-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7527066b-2e69-48d6-9fb7-f3df364e51b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-09-06 14:04:12 UTC
Reply
Permalink
Raw Message
Post by PMario
Post by Lost Admin
1) Set-up a WebDAV server on Apache (follow the Apache instructions,
nothing special).
:) .. I was thinking about a IIS testcase. .. Will run some tests
There is a video about setting up IIS. I agree, it would be good to test
the popular web servers that support WebDAV and eventually collect sets of
instructions on setting them up.

I was planning on reviewing the video (from another thread) and setting up
IIS on my home computer (Windows 10 Home) if it is possible as a test
environment for IIS. I haven't gotten around to it. Apache is my preferred
web server. I messed with lighttpd because it has a smaller memory
footprint. Someone should probably test things with Nginx as well (but it
won't be me).
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/8d5574e8-e6b9-405b-a124-d14f06ec7a70%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
PMario
2017-09-06 16:16:44 UTC
Reply
Permalink
Raw Message
... Someone should probably test things with Nginx as well (but it won't
be me).
IMO no need to go with Nginx atm. It only implements basic support
http://nginx.org/en/docs/http/ngx_http_dav_module.html ... which will cause
trouble.

-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/f3f07a34-b9ff-41dc-83f5-aa38fca62847%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-09-07 14:48:06 UTC
Reply
Permalink
Raw Message
I've been trying to dig into the proper specs on the use of ETag and it
looks like it is only supposed to be sent from the server along with the
data. Thus the PUT request is not supposed to include a new ETag. I *think* Apache
is actually doing it right.

Also, I did the same series of screenshots on my test Lighttpd server
(which doesn't experience the same 412 error) and for some reason, the
If-Match header gets dropped from the subsequent PUT requests headers. I
don't know why it would be different as I think that header is coming from
the client side.
Post by Arlen Beiler
It is becoming pretty clear that for some reason the Etag is not being set
in the response header, nor anything else equivalent to it. Per our
discussion privately, it does seem that this is an Apache issue, however I
have not been able to look into it further.
-
https://fullstackhack.wordpress.com/2014/12/10/the-pain-of-etags-mod_deflate-apache-2-4-and-tomcat-7/
- https://httpd.apache.org/docs/2.4/caching.html
At some point I will test it on one of my servers and see if I can get it
working. However, it is obvious that this is the problem. One option would
be to make a second head request if the 204 response does not contain an
Etag, but I guess that wouldn't be atomic either.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/a827b52a-100c-453d-b146-a48d229be428%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Arlen Beiler
2017-09-07 20:59:06 UTC
Reply
Permalink
Raw Message
Ok, so how *does* web dav take care of making sure someone is editing the
latest version? Or does it use the entirely file-system concept of locking
files for editing?

Are we barking up the wrong tree with the idea of using web DAV? It is
entirely file system centered. The fact that it can handle web requests
seems almost incidental. Or maybe it is just the simple fact that the PUT
saver nowhere near implements the entire DAV protocol.

What protocol talks about Etags in 204 responses? The one I found only
mentions it once in relation to a PUT request by saying that there is no
specific definition of whether it should guarantee the file content is
exactly byte-for-byte identical to the PUT request.
http://www.ietf.org/rfc/rfc4918.txt

The HTTP/1.1 spec is at https://www.ietf.org/rfc/rfc2616.txt

I can't find anything in either of those just by searching for "etag".

Just some thoughts.
Post by Lost Admin
I've been trying to dig into the proper specs on the use of ETag and it
looks like it is only supposed to be sent from the server along with the
data. Thus the PUT request is not supposed to include a new ETag. I
*think* Apache is actually doing it right.
Also, I did the same series of screenshots on my test Lighttpd server
(which doesn't experience the same 412 error) and for some reason, the
If-Match header gets dropped from the subsequent PUT requests headers. I
don't know why it would be different as I think that header is coming from
the client side.
Post by Arlen Beiler
It is becoming pretty clear that for some reason the Etag is not being
set in the response header, nor anything else equivalent to it. Per our
discussion privately, it does seem that this is an Apache issue, however I
have not been able to look into it further.
- https://fullstackhack.wordpress.com/2014/12/10/the-pain-of-
etags-mod_deflate-apache-2-4-and-tomcat-7/
<https://fullstackhack.wordpress.com/2014/12/10/the-pain-of-etags-mod_deflate-apache-2-4-and-tomcat-7/>
- https://httpd.apache.org/docs/2.4/caching.html
At some point I will test it on one of my servers and see if I can get it
working. However, it is obvious that this is the problem. One option would
be to make a second head request if the 204 response does not contain an
Etag, but I guess that wouldn't be atomic either.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/
msgid/tiddlywiki/a827b52a-100c-453d-b146-a48d229be428%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/a827b52a-100c-453d-b146-a48d229be428%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdSQXjc%3DyJJT6qLyyzJf%2B%3DCR3%2Bu4ZcFFm5kvGuVgsRv%2B20w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-09-08 12:50:40 UTC
Reply
Permalink
Raw Message
I was looking through the Apache (which is a bit unfair) and www.webdav.org
sites. I inferred a lot of what I think I understand.

From what I can tell, there is no solid solution for data locking with
WebDAV itself but there are some options available:

WebDAV does have a built-in locking mechanism. Apache does support it but
you have to turn it on. I haven't researched this one very far beyond
reading about it's existence. The client would need to send a lock request
(I haven't figured out how that is done yet) before (or during?) the GET
request. Then use some reference to that with the PUT request. After that,
as I understand it, the calling application would need to request a new
lock after the PUT to continue editing (although that might actually be a
misunderstanding on my part). Sorry, I can't find the reference to this now.

For hard locks WebDAV Locks, the most coherent explantion I found
is http://www.webdav.org/mod_dav/install.html#apache (part way down,
beginning with Enabling DAV).

Apache support two methods of "lazy updates". A lazy update is where the
application doesn't actually request a lock. Instead the requesting
application sends a "update based on some earlier version based on some
value" and if the file hasn't been changed since that value was current,
then the update happens, otherwise you get the 412. The two choices (for
Apache) that I've found are:

ETag and If-Match, which we currently only sort-of use right (based on how
Apache behaves). I don't have a good clear single source of information. I
read a bunch of blogs from programmers complaining about it (not
specifically related to WebDAV) and a variety of Apache docs on cache
control.

If-Modified-Since header, which is based on the timestamp of the GET
request. I stumbled across this one in a blog post but now I can't find it.

Both of the ETag/If-Match and If-Modified-Since are actually cache control
mechanisms.

Sorry for my crappy references.


In my personal opinion, I do think that ETag (or If-Modified-Since) is the
way to go but we need to figure out a way to either get one back as a
response to a PUT request (I've been trying to figure this out but so far
have failed) or to figure out a way to do a follow-up GET request to reload
the file from the WebDAV server after saving.


If you look at the series of screenshots I created
(https://wiki.suntrap.ca/davsaver.html), you will note that although
Lighttpd doesn't send a 412 with the second PUT request, the ETag/If-Match
is dropped in the 2nd PUT request. I *think* something has happened to
remove all file locking protections after the first PUT. I haven't had time
to set-up a working IIS test environment or I would have that sequence
set-up too.
Post by Arlen Beiler
Ok, so how *does* web dav take care of making sure someone is editing the
latest version? Or does it use the entirely file-system concept of locking
files for editing?
Are we barking up the wrong tree with the idea of using web DAV? It is
entirely file system centered. The fact that it can handle web requests
seems almost incidental. Or maybe it is just the simple fact that the PUT
saver nowhere near implements the entire DAV protocol.
What protocol talks about Etags in 204 responses? The one I found only
mentions it once in relation to a PUT request by saying that there is no
specific definition of whether it should guarantee the file content is
exactly byte-for-byte identical to the PUT request.
http://www.ietf.org/rfc/rfc4918.txt
The HTTP/1.1 spec is at https://www.ietf.org/rfc/rfc2616.txt
I can't find anything in either of those just by searching for "etag".
Just some thoughts.
Post by Lost Admin
I've been trying to dig into the proper specs on the use of ETag and it
looks like it is only supposed to be sent from the server along with the
data. Thus the PUT request is not supposed to include a new ETag. I
*think* Apache is actually doing it right.
Also, I did the same series of screenshots on my test Lighttpd server
(which doesn't experience the same 412 error) and for some reason, the
If-Match header gets dropped from the subsequent PUT requests headers. I
don't know why it would be different as I think that header is coming from
the client side.
Post by Arlen Beiler
It is becoming pretty clear that for some reason the Etag is not being
set in the response header, nor anything else equivalent to it. Per our
discussion privately, it does seem that this is an Apache issue, however I
have not been able to look into it further.
-
https://fullstackhack.wordpress.com/2014/12/10/the-pain-of-etags-mod_deflate-apache-2-4-and-tomcat-7/
- https://httpd.apache.org/docs/2.4/caching.html
At some point I will test it on one of my servers and see if I can get
it working. However, it is obvious that this is the problem. One option
would be to make a second head request if the 204 response does not contain
an Etag, but I guess that wouldn't be atomic either.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/a827b52a-100c-453d-b146-a48d229be428%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/a827b52a-100c-453d-b146-a48d229be428%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/4d3e7efd-1b67-489b-906b-d07078bb18a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-09-08 13:00:03 UTC
Reply
Permalink
Raw Message
We should just completely ignore Lighttpd as it isn't doing any locking at
all. I just tried to force an error with two different browsers that should
have resulted the 2nd one getting an error. Instead, the second one
overwrote the first. Lighttpd might be sending an ETag, but it is ignoring
the If-Match.
If you look at the series of screenshots I created (
https://wiki.suntrap.ca/davsaver.html), you will note that although
Lighttpd doesn't send a 412 with the second PUT request, the ETag/If-Match
is dropped in the 2nd PUT request. I *think* something has happened to
remove all file locking protections after the first PUT. I haven't had time
to set-up a working IIS test environment or I would have that sequence
set-up too.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/fc8d1218-90ba-4435-9189-9e129ea0af92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-09-14 19:23:30 UTC
Reply
Permalink
Raw Message
I finally found something that properly talks about Etags. You can infer
why we don't get an ETag header in the response to a PUT (for both Apache
and
IIS). https://stackoverflow.com/questions/42246577/why-responses-to-put-requests-must-not-provide-an-etag

You can skip going to the link if you want to. It is asking for an
explanation of when to send an ETag or not and I think we can use what it
quotes to get the understanding.

*An origin server MUST NOT send a validator header field* (Section 7.2
<https://tools.ietf.org/html/rfc7231#section-7.2>), such as an ETag or
Last-Modified field, in a successful response to PUT unless the request's
representation data was saved without any transformation applied to the
body (i.e., the resource's new representation data is identical to the
representation data received in the PUT request) and the validator field
value reflects the new representation. This requirement allows a user agent
to know when the representation body it has in memory remains current as a
result of the PUT, thus not in need of being retrieved again from the
origin server, and that *the new validator(s) received in the response can
be used for future conditional requests* in order to prevent accidental
overwrites (Section 5.2 <https://tools.ietf.org/html/rfc7231#section-5.2>).

Apache (and IIS) allow for the server to be configured such that you can
add a custom processor to specific HTTP actions (like PUT) that are
completely independent of WebDAV (I forget how but I did one for a post
call once because we didn't have source and needed to re-mangle some of the
user input).

This means that the Apache web server doesn't know for sure that what you
send in the PUT through WebDAV will be what it picks up on the next GET.
So, can't send and updated ETag.

I imagine the same goes for IIS.

Lighttpd doesn't appear to honor etag and If-Match headers so Lighttpd is
broken. Nginx (I've been told) has a very primitive webdav module so is
also not suitable for this discussion.
Post by Arlen Beiler
Ok, so how *does* web dav take care of making sure someone is editing the
latest version? Or does it use the entirely file-system concept of locking
files for editing?
Are we barking up the wrong tree with the idea of using web DAV? It is
entirely file system centered. The fact that it can handle web requests
seems almost incidental. Or maybe it is just the simple fact that the PUT
saver nowhere near implements the entire DAV protocol.
What protocol talks about Etags in 204 responses? The one I found only
mentions it once in relation to a PUT request by saying that there is no
specific definition of whether it should guarantee the file content is
exactly byte-for-byte identical to the PUT request.
http://www.ietf.org/rfc/rfc4918.txt
The HTTP/1.1 spec is at https://www.ietf.org/rfc/rfc2616.txt
I can't find anything in either of those just by searching for "etag".
Just some thoughts.
Post by Lost Admin
I've been trying to dig into the proper specs on the use of ETag and it
looks like it is only supposed to be sent from the server along with the
data. Thus the PUT request is not supposed to include a new ETag. I
*think* Apache is actually doing it right.
Also, I did the same series of screenshots on my test Lighttpd server
(which doesn't experience the same 412 error) and for some reason, the
If-Match header gets dropped from the subsequent PUT requests headers. I
don't know why it would be different as I think that header is coming from
the client side.
Post by Arlen Beiler
It is becoming pretty clear that for some reason the Etag is not being
set in the response header, nor anything else equivalent to it. Per our
discussion privately, it does seem that this is an Apache issue, however I
have not been able to look into it further.
-
https://fullstackhack.wordpress.com/2014/12/10/the-pain-of-etags-mod_deflate-apache-2-4-and-tomcat-7/
- https://httpd.apache.org/docs/2.4/caching.html
At some point I will test it on one of my servers and see if I can get
it working. However, it is obvious that this is the problem. One option
would be to make a second head request if the 204 response does not contain
an Etag, but I guess that wouldn't be atomic either.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/a827b52a-100c-453d-b146-a48d229be428%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/a827b52a-100c-453d-b146-a48d229be428%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/3206b23b-d4e5-4fe3-8984-70b449b7218c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-10-10 17:13:32 UTC
Reply
Permalink
Raw Message
Further on the complexity of ETag and why Apache (and generic web servers)
should not send an updated ETag in response to a PUT:

https://tools.ietf.org/id/draft-reschke-http-etag-on-write-09.html
Post by Lost Admin
I finally found something that properly talks about Etags. You can infer
why we don't get an ETag header in the response to a PUT (for both Apache
and IIS).
https://stackoverflow.com/questions/42246577/why-responses-to-put-requests-must-not-provide-an-etag
You can skip going to the link if you want to. It is asking for an
explanation of when to send an ETag or not and I think we can use what it
quotes to get the understanding.
*An origin server MUST NOT send a validator header field* (Section 7.2
<https://tools.ietf.org/html/rfc7231#section-7.2>), such as an ETag or
Last-Modified field, in a successful response to PUT unless the request's
representation data was saved without any transformation applied to the
body (i.e., the resource's new representation data is identical to the
representation data received in the PUT request) and the validator field
value reflects the new representation. This requirement allows a user agent
to know when the representation body it has in memory remains current as a
result of the PUT, thus not in need of being retrieved again from the
origin server, and that *the new validator(s) received in the response
can be used for future conditional requests* in order to prevent
accidental overwrites (Section 5.2
<https://tools.ietf.org/html/rfc7231#section-5.2>).
Apache (and IIS) allow for the server to be configured such that you can
add a custom processor to specific HTTP actions (like PUT) that are
completely independent of WebDAV (I forget how but I did one for a post
call once because we didn't have source and needed to re-mangle some of the
user input).
This means that the Apache web server doesn't know for sure that what you
send in the PUT through WebDAV will be what it picks up on the next GET.
So, can't send and updated ETag.
I imagine the same goes for IIS.
Lighttpd doesn't appear to honor etag and If-Match headers so Lighttpd is
broken. Nginx (I've been told) has a very primitive webdav module so is
also not suitable for this discussion.
Post by Arlen Beiler
Ok, so how *does* web dav take care of making sure someone is editing
the latest version? Or does it use the entirely file-system concept of
locking files for editing?
Are we barking up the wrong tree with the idea of using web DAV? It is
entirely file system centered. The fact that it can handle web requests
seems almost incidental. Or maybe it is just the simple fact that the PUT
saver nowhere near implements the entire DAV protocol.
What protocol talks about Etags in 204 responses? The one I found only
mentions it once in relation to a PUT request by saying that there is no
specific definition of whether it should guarantee the file content is
exactly byte-for-byte identical to the PUT request.
http://www.ietf.org/rfc/rfc4918.txt
The HTTP/1.1 spec is at https://www.ietf.org/rfc/rfc2616.txt
I can't find anything in either of those just by searching for "etag".
Just some thoughts.
Post by Lost Admin
I've been trying to dig into the proper specs on the use of ETag and it
looks like it is only supposed to be sent from the server along with the
data. Thus the PUT request is not supposed to include a new ETag. I
*think* Apache is actually doing it right.
Also, I did the same series of screenshots on my test Lighttpd server
(which doesn't experience the same 412 error) and for some reason, the
If-Match header gets dropped from the subsequent PUT requests headers. I
don't know why it would be different as I think that header is coming from
the client side.
Post by Arlen Beiler
It is becoming pretty clear that for some reason the Etag is not being
set in the response header, nor anything else equivalent to it. Per our
discussion privately, it does seem that this is an Apache issue, however I
have not been able to look into it further.
-
https://fullstackhack.wordpress.com/2014/12/10/the-pain-of-etags-mod_deflate-apache-2-4-and-tomcat-7/
- https://httpd.apache.org/docs/2.4/caching.html
At some point I will test it on one of my servers and see if I can get
it working. However, it is obvious that this is the problem. One option
would be to make a second head request if the 204 response does not contain
an Etag, but I guess that wouldn't be atomic either.
--
You received this message because you are subscribed to the Google
Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/a827b52a-100c-453d-b146-a48d229be428%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/a827b52a-100c-453d-b146-a48d229be428%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/e0847c74-3200-4c68-9257-f2ac1983ff3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
@TiddlyTweeter
2017-10-10 17:27:04 UTC
Reply
Permalink
Raw Message
Where are we with this?

Could a newbie cope?

Is the install outlined above consistent & reliable?

Josiah
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/ac535b80-9627-4c77-9331-09ade2c6ca12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-10-10 18:13:27 UTC
Reply
Permalink
Raw Message
If you are familiar with setting up Apache, you could definitely set-up an
Apache WebDav server. I just followed some generic how-to guides that
explains the settings needed to get WebDav, TLS (and letsencrypt), and
authentication working on Apache.

The issue is with using TiddlyWiki. When you save your wiki, it sends an
HTTP PUT method request. You either get a normal save (like we are used to
with TiddlyWiki) or a somewhat cryptic 412 error.

The 412 error indicates the save didn't happen because the version on the
server is "newer" than the version your browser has. It works nicely when
multiple people try to edit the same TiddlyWiki file (I tested this myself).

Unfortunately, in order to get the magic ETag value after you save a
change, you need to reload TiddlyWiki because you don't get an update to it
after the PUT request.

*Note:* ETag is just an HTTP header that the server sends with a GET
request. It changes when the file changes. When TiddlyWiki saves (does the
PUT) it sends the ETag back to the server effectively saying, "save the
file if the ETag is this otherwise give me an error".

I am planning on writing up a full setup guide to create your own WebDav
server using Apache, TLS, Letsencrypt, and HTTP Basic Auth (in digest mode)
but I'm not going to until it works properly. Which means without needing
to reload. Sadly, my programming skills are seriously lacking. I think I
know what should be done in TiddlyWiki's webdav saver, but I don't have the
skills to do it.
Post by @TiddlyTweeter
Where are we with this?
Could a newbie cope?
Is the install outlined above consistent & reliable?
Josiah
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/ae046ac5-7a7a-437b-a910-020aaeab0d40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-10-18 13:12:00 UTC
Reply
Permalink
Raw Message
Could someone help me a bit with something? My coding skills are not up to
even this simple task sadly.

The WebDAV saver for TiddlyWiki saves using the HTTP PUT method.
Unfortunately the Apache and IIS implementations of WebDAV do not respond
with the updated ETag header. However, according to the documentation, the
HTTP HEAD method should respond with the new ETAG. So, I would like to
modify the WebDAV saver to do the following:

1) call the HTTP LOCK method to lock the file
2) call the HTTP PUT method to save the file (as it does today with the
ETAG and everything)

3) If save fails: return the error message (like we do today)
4) if save succeeds: call the HTTP HEAD method to get the updated ETag

5) call the HTTP UNLOCK method to release the lock on the file

NOTES:

If I read the documentation correctly, HTTP locks have a timeout. So if an
issue occurs during the locked phase, the file should be released in a few
minutes.

I'm not bothering to actually check if we got a lock after step 1 because
we will still get an error from the PUT call due to either another file
lock or the ETag miss-match.

The UNLOCK response doesn't need to be communicated to the end-user because
it should only fail if the initial lock failed (or there is some miss-match
in the lock token). This could even be done asynchronously.

We could conceivably use the HTTP LOCK method to lock a tiddlywiki when it
is being edited but the LOCK method has a timeout, so we would need to
periodically re-request the lock. Right now I prefer the opportunistic
locking method we are using with ETag. The only reason to use the lock
around the PUT and HEAD calls is to ensure that the ETag we get is the one
that matches the data we just saved and not the data submitted by another
person at almost the same time.

In Apache, the lock method is optional and requires some additional set-up.
By ignoring the success/failure of the lock, we nicely fall-back to the
current ETag method.

Thoughts? Suggestions? Pointers to where I find the parts of the WebDAV
saver code in tiddlywiki to attempt to make these changes myself?
Post by Arlen Beiler
Ok, so how *does* web dav take care of making sure someone is editing the
latest version? Or does it use the entirely file-system concept of locking
files for editing?
Are we barking up the wrong tree with the idea of using web DAV? It is
entirely file system centered. The fact that it can handle web requests
seems almost incidental. Or maybe it is just the simple fact that the PUT
saver nowhere near implements the entire DAV protocol.
What protocol talks about Etags in 204 responses? The one I found only
mentions it once in relation to a PUT request by saying that there is no
specific definition of whether it should guarantee the file content is
exactly byte-for-byte identical to the PUT request.
http://www.ietf.org/rfc/rfc4918.txt
The HTTP/1.1 spec is at https://www.ietf.org/rfc/rfc2616.txt
I can't find anything in either of those just by searching for "etag".
Just some thoughts.
Post by Lost Admin
I've been trying to dig into the proper specs on the use of ETag and it
looks like it is only supposed to be sent from the server along with the
data. Thus the PUT request is not supposed to include a new ETag. I
*think* Apache is actually doing it right.
Also, I did the same series of screenshots on my test Lighttpd server
(which doesn't experience the same 412 error) and for some reason, the
If-Match header gets dropped from the subsequent PUT requests headers. I
don't know why it would be different as I think that header is coming from
the client side.
Post by Arlen Beiler
It is becoming pretty clear that for some reason the Etag is not being
set in the response header, nor anything else equivalent to it. Per our
discussion privately, it does seem that this is an Apache issue, however I
have not been able to look into it further.
-
https://fullstackhack.wordpress.com/2014/12/10/the-pain-of-etags-mod_deflate-apache-2-4-and-tomcat-7/
- https://httpd.apache.org/docs/2.4/caching.html
At some point I will test it on one of my servers and see if I can get
it working. However, it is obvious that this is the problem. One option
would be to make a second head request if the 204 response does not contain
an Etag, but I guess that wouldn't be atomic either.
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:>.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/a827b52a-100c-453d-b146-a48d229be428%40googlegroups.com
<https://groups.google.com/d/msgid/tiddlywiki/a827b52a-100c-453d-b146-a48d229be428%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/4429901c-fc17-4536-afcb-1069dafe5ee8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Arlen Beiler
2017-10-18 13:16:38 UTC
Reply
Permalink
Raw Message
The webdav saver code in TiddlyWiki should be in
$:/core/modules/savers/put.js or something like that. I know it ends with
put.js

On Oct 18, 2017 09:12, "Lost Admin" <***@gmail.com> wrote:

Could someone help me a bit with something? My coding skills are not up to
even this simple task sadly.

The WebDAV saver for TiddlyWiki saves using the HTTP PUT method.
Unfortunately the Apache and IIS implementations of WebDAV do not respond
with the updated ETag header. However, according to the documentation, the
HTTP HEAD method should respond with the new ETAG. So, I would like to
modify the WebDAV saver to do the following:

1) call the HTTP LOCK method to lock the file
2) call the HTTP PUT method to save the file (as it does today with the
ETAG and everything)

3) If save fails: return the error message (like we do today)
4) if save succeeds: call the HTTP HEAD method to get the updated ETag

5) call the HTTP UNLOCK method to release the lock on the file

NOTES:

If I read the documentation correctly, HTTP locks have a timeout. So if an
issue occurs during the locked phase, the file should be released in a few
minutes.

I'm not bothering to actually check if we got a lock after step 1 because
we will still get an error from the PUT call due to either another file
lock or the ETag miss-match.

The UNLOCK response doesn't need to be communicated to the end-user because
it should only fail if the initial lock failed (or there is some miss-match
in the lock token). This could even be done asynchronously.

We could conceivably use the HTTP LOCK method to lock a tiddlywiki when it
is being edited but the LOCK method has a timeout, so we would need to
periodically re-request the lock. Right now I prefer the opportunistic
locking method we are using with ETag. The only reason to use the lock
around the PUT and HEAD calls is to ensure that the ETag we get is the one
that matches the data we just saved and not the data submitted by another
person at almost the same time.

In Apache, the lock method is optional and requires some additional set-up.
By ignoring the success/failure of the lock, we nicely fall-back to the
current ETag method.

Thoughts? Suggestions? Pointers to where I find the parts of the WebDAV
saver code in tiddlywiki to attempt to make these changes myself?
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJ1vdST21KdCqiX8FZRs7kKAJh%2BZmEWRsPKxNmBKOEbMZ0aqgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
PMario
2017-10-18 15:26:19 UTC
Reply
Permalink
Raw Message
Post by Lost Admin
Could someone help me a bit with something? My coding skills are not up to
even this simple task sadly.
The WebDAV saver for TiddlyWiki saves using the HTTP PUT method.
Unfortunately the Apache and IIS implementations of WebDAV do not respond
with the updated ETag header. However, according to the documentation, ....
Hi, Can you add some links to your docs? Especially the ETag handling
stuff, that you refer to?

-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7859bb90-fcf6-4638-89a4-5e7db2b66a19%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Lost Admin
2017-10-18 17:44:02 UTC
Reply
Permalink
Raw Message
I can't currently find what I was reading that showed me that HEAD gets an
e-tag, but this blog indicates it does:

http://joshua.schachter.org/2006/11/apache-etags

But I did use this one in my research. It explains why the Etag doesn't
usually show up with a PUT.

https://stackoverflow.com/questions/42246577/why-responses-to-put-requests-must-not-provide-an-etag

The apache docs location should be obvious. I had to read the cache control
and mod_dav, mod_dav_fs, and mod_headers section to sort out that Apache is
not able to confirm that what as sent in the PUT will be exactly what is
returned for the next GET request. So, no etag header.

I can show (because I tested) that the HEAD method does appear to return an
etag.

<Loading Image...>
Post by PMario
Post by Lost Admin
Could someone help me a bit with something? My coding skills are not up
to even this simple task sadly.
The WebDAV saver for TiddlyWiki saves using the HTTP PUT method.
Unfortunately the Apache and IIS implementations of WebDAV do not respond
with the updated ETag header. However, according to the documentation, ....
Hi, Can you add some links to your docs? Especially the ETag handling
stuff, that you refer to?
-m
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/b9996c29-8f7d-4d77-801d-789e64a55894%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...