A brief introduction to webdav-src
Introduction
Once upon a time, there was a protocol called WebDAV (Web Distributed Authoring and Versioning).
WebDAV extended HTTP to make it bi-directional: As well as retrieving documents from a web server, it let you edit them and then publish them back again. This was considered a good thing.
The problem
Unfortunately, there was a problem. Some HTML editing applications assumed that all web sites were static content, and that there was no difference between the source of an HTML document and what appeared on screen in a web browser. These applications would request the rendered view of a document, even if the document was generated by PHP or some other sort of server-side scripting language. After editing, the application would then upload a new (static) HTML version, usually overwriting the carefully crafted template which was supposed to be rendered by the server.
This caused much growling, roaring and gnashing of teeth.
The solution
Zope guy Ethan Fremen came up with a solution: Tweak your web app server or content management system to serve a special flavour of WebDAV on a different port, which will always provide the source of the document, regardless of whether the application asked for the source or the rendered version. This looked a bit crap in a web browser, but it was genius for feeding source (and only the source) to broken editors like Dreamweaver. Of course, this also neatly broke all that was clever about WebDAV in the first place, reducing it to a kind of ghetto cousin to FTP, but that was the price we paid, back then, for fancy-pants GUI HTML editors.
Wearing his Zope Corporation hat, Ethan convinced IANA to let him have port 9800/tcp to serve this magical always-source flavour of WebDAV, and for a while, everyone was happy.
The nightmare continues
A year or so later, I found myself running a largish project that used WebDAV, and had folks from all around the world working on it. This raised some obvious questions, since none of the editing work was encrypted, and WebDAV, like HTTP, transfers usernames and passwords as either plain text or trivially obfuscated text. The logical solution was to shift the editing to HTTPS, and thus use SSL to secure the transmission. This ran smack-bang into the original problem Ethan had already set out to solve: The HTTP server would respect a broken client request for the rendered version when it really wanted the source version, and the whole wretched circus started all over again.
Can't stop the rock
Later that day, after restoring from a backup and doing quite a lot of shouting, I wrote some documentation (long since lost), put together an application, and herded it through the IANA approval process. The inimitable John Crain gruffly denied my request for the cutesy 9843/tcp (9800 and 443, geddit?), and instead stuck us with the much less interesting 9802.
This allocation was greeted with a huge blaze of no enthusiasm whatsoever. Somewhere, off in the distance, a dog barked.
Aftermath
Ethan moved on to greener pastures, and so did I.
The dimwits on the plone project decided to use port 1980/tcp, which was already assigned to something else, for the WebDAV source view. No one seems to know why they did this.
I wrote this page in an attempt to reduce the number of people emailing me and asking what this port was for.
There is a growing suspicion amongst skilled professionals that perhaps Dreamweaver is Not All That.
9843/tcp remains unallocated.