Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Samba and web pages



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

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org