<div dir="ltr"><meta charset="utf-8">Actually, directory indexes are standardized in WebDAV. If the problem with using HTTP is that the directory listings aren't provided in a standardized format across Apache and IIS but rather are in a sort of ad hoc HTML format, a solution could be to provide a custom directory index handler that returns a WebDAV collection (with depth = 1) which is in the WebDAV XML format. Normally (<a href="http://en.wikipedia.org/wiki/WebDAV">according</a> to Wikipedia), WebDAV specifies you use a <span class="Apple-style-span" style="font-family: sans-serif; font-size: 13px; line-height: 19px; "><a href="http://msdn.microsoft.com/en-us/library/aa142960%28EXCHG.65%29.aspx">PROPFIND</a> </span>WebDAV HTTP method when requesting a directory to "retrieve the collection structure (a.k.a. directory hierarchy) of a remote system", but there's no reason why you can't also return this same XML content type when performing a GET request of a directory. <div>
<div><br></div><div>For example, issuing a PROPFIND request of a WordPress SVN tag, which when making a GET request returns the regular Apache directory listing: </div><div><br></div><div><font class="Apple-style-span" face="'courier new', monospace">curl -i -H "Depth: 1" -X PROPFIND <a href="http://svn.automattic.com/wordpress/tags/3.0.1">http://svn.automattic.com/wordpress/tags/3.0.1</a></font></div>
<div><br></div><div>Here's the output: <a href="https://gist.github.com/05c389c81ccc8fc2f20b">https://gist.github.com/05c389c81ccc8fc2f20b</a></div><div><div><br><div><div><div><div><div><div><div><div>This same standard WebDAV format could be the response of a regular GET request. In Apache, this could be accomplished by writing an mod_rewrite rule which matches all directory requests and directs them to a PHP script which returns the directory listing in the WebDAV XML format, for example:</div>
<div><br></div><div><div><font class="Apple-style-span" face="'courier new', monospace"><IfModule mod_rewrite.c></font></div><div><font class="Apple-style-span" face="'courier new', monospace">RewriteEngine On</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">RewriteCond %{REQUEST_FILENAME} -d</font></div><div><font class="Apple-style-span" face="'courier new', monospace">RewriteRule . /path/to/directory-list.php [L]</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace"></IfModule></font></div></div><div><br></div><div>Just a thought,</div><div>Weston</div><div><br></div><div><br><div class="gmail_quote">On Sun, Nov 7, 2010 at 3:22 AM, Nic Carter <span dir="ltr"><<a href="mailto:niccarter@mac.com">niccarter@mac.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Thanks for the long reply. :) It is frustrating that some things are designed really well and other bits are painful, like getting a listing of files...<br>
<br>
ok, so, I did take a quick look at my code and one way of fixing the Xiphos listing, for example, is by not trying to parse the file sizes. We could trust the module size provided in the module conf (which isn't always provided and is sometimes wrong!) and then simply have a total size indicator rather than have an indicator for each file downloaded in the module. I think that may also work for <a href="http://bible.org" target="_blank">bible.org</a>? Would be an option, and then we'd need to check to see if the file size returned by FTPTransport::getDirList() is zero, and if it is, use the total size provided by the module conf. But, I believe there is a way of telling the size of a file being retrieved via HTTP GET? hopefully we could use that as well? :)<br>
<br>
Anyway, just a quick thought. Of course, I'd prefer that we didn't try to parse a file listing like this . . . and would rather we used the mods.d.tar.gz file & module ZIP files, but more on that in another email. :)<br>
<br>
<br>
Thanks, ybic<br>
<font color="#888888"> nic... :)<br>
</font><br>
ps: I wouldn't be against someone submitting something to w3c, but I wouldn't be holding my breath for it to be implemented, let alone approved... :( :(<br>
<div><div></div><div class="h5"><br>
On 06/11/2010, at 10:15 PM, Troy A. Griffitts wrote:<br>
<br>
> On 11/06/2010 04:36 AM, Nic Carter wrote:<br>
><br>
>> I initially submitted a patch for HTTP parsing, but it only<br>
>> works for CrossWire and not for the Bible.org nor for the Xiphos<br>
>> repos, and I have no intention of modifying the parsing code even<br>
>> more in order to try to support more web servers!<br>
><br>
> :) thanks for the patch! Yeah, surprisingly even FTP directory parsing<br>
> is painful. Even libCURL doesn't have an FTP directory listing parse<br>
> function. I couldn't believe that when I wrote the FTP code! We found<br>
> a portable library call ftpparse which parses directory listings for us.<br>
> When doing the HTTP transport, I was hopeful we might find an<br>
> httpdirparse or something :) But no such luck, as of yet.<br>
><br>
> We were talking on #sword the other day about how odd it is that there<br>
> is no w3c standard for the obvious use case:<br>
><br>
> Browse a hierarchy of folders+resources and retrieve some.<br>
><br>
> I brought this up with a frequent member of w3c committees and he<br>
> suggested we develop a silly stupid minimal schema to represent a<br>
> resource tree and a) submit it for w3c approval, and b) submit updates<br>
> for Apache and IIS to update their Folder Index listings to comply to<br>
> the proposal. e.g., something like,<br>
><br>
> <?stylesheet href="apache_look_and_feel.css"?><br>
> <folder name="My Documents"><br>
> <resource<br>
> type="file" mimetype="application/msword" name="War Of the Worlds.doc"/><br>
> </folder><br>
><br>
> Then, end users wouldn't notice a difference, and we could have a<br>
> standard to easily parse. As always, you know who is always in the<br>
> details: attributes for permissions, mtime...; do you make the whole<br>
> subdirectory hierarchy available from a directory request, or just the<br>
> immediate children...<br>
><br>
> Anyway, we can dream of a bold new Internet where everything is<br>
> standardized and straightforward for developers... :) ahhhhh.<br>
><br>
><br>
> Troy<br>
><br>
> _______________________________________________<br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above page<br>
<br>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Weston Ruter<br><a href="http://weston.ruter.net/" target="_blank">http://weston.ruter.net/</a><br><font size="1"><a href="http://twitter.com/westonruter" target="_blank">@westonruter</a> - <a href="http://www.google.com/profiles/WestonRuter#about" target="_blank">Google Profile</a></font><br>
</div><br>
</div></div></div></div></div></div></div></div></div></div></div></div>