| Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | About BLU |
Assuming I understand you correctly, you're just typing a directory path
into your browser's address bar, and you'd like some server along the
way to do the right magic so the index page is returned to the browser.
I don't believe this is possible. Here's why.
When you enter a string beginning with "http:" into your browser's
location bar, the browser sends a request to a webserver somewhere on
the network, and the webserver (if appropriately configured) will return
the correct index{.html,htm,php,...} file if one exists. But when you
enter a string beginning with "file:" (or a string beginning with "/"
which implies "file:" protocol), the browser simply issues standard
filesystem I/O calls to the kernel (open(2), read(2), getdents(2), or
the obsolete readdir(2), etc.). Note that the section 2 system calls
I'm referring to may not be called directly by the browser. They may be
wrapped in libc functions documented in section 3 of the manpages. But
internally those libc functions will end up issuing the system calls.
The kernel has no special knowledge that the application is a web
browser. To the kernel, the browser is an ordinary application that
happens to be issuing system calls to read the contents of a directory.
>From the kernel's perspective, the web browser is no different than
"ls". Deep in the bowels of the kernel is the knowledge that the
particular directory you're accessing must be fetched by talking SMB
protocol to an SMB server elsewhere on the network, so the kernel
fetches the data through the SMB device driver rather than the IDE or
SCSI or USB device driver. But the kernel still has to return the
result in a structure appropriate to the system call made by the
application. The API for the system calls issued by the web browser
when doing "file:" protocol on a directory don't allow for returning the
contents of a file. They return struct dirent []. So, even if the SMB
server could be configured to return the contents of an index file when
a directory was requested, the kernel would have no way to pass that
information back to the application. And even if it could, it would be
a bad thing because, since the SMB server doesn't know who's requesting
the information, if it returned the contents of some index file instead
of a list of directory entries, ordinary applications like "ls" would
break when trying to do a directory listing.
When you bring a webserver into the picture instead of a filesystem
server, the situation changes radically. The browser is speaking "http"
to the webserver, and the webserver is returning plain text formatted as
an HTML document. Unlike the case of an application issuing system
calls that have a different API depending on whether a directory or a
normal file is being read, a webbrowser makes the same HTTP request
regardless of whether the object being fetched is a directory or a
file. The webserver sends back text formatted as HTML either way.
Mark Rosenthal
Jerry Feldman wrote:
> I'm using Samba to export a number of Linux directories locally.
> However, when I open those directories in the browser, I get a
> directory, as expected. Is there a way I can configure it such that the
> browser brings up the index page? Alternatively, I could achieve what I
> want by running Apache, but I don't want to do that.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
Discuss mailing list
[hidden email]
http://lists.blu.org/mailman/listinfo/discuss