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 | Bling | 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
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |