Re: reiser4 plugins

From: David Masover (ninja_at_slaphack.com)
Date: 07/01/05

  • Next message: Vojtech Pavlik: "Re: [PATCH] deinline sleep/delay functions" 
    Date:	Fri, 01 Jul 2005 02:47:55 -0500
To: Hubert Chan <hubert@uhoreg.ca>

    Hubert Chan wrote:
    > On Thu, 30 Jun 2005 08:29:56 +0200, David Weinehall <tao@acc.umu.se> said:
    >
    >
    >>On Thu, Jun 30, 2005 at 12:33:10AM -0400, Hubert Chan wrote:
    >>
    >>>It's sort of like the way web servers handle index.html, for those
    >>>who think it's a stupid idea. (Of course, some people may still
    >>>think it's a stupid idea... ;-) )
    >
    >
    >>And guess what? That's handled on the web server level (userland),
    >>not by the file system. So different web servers can handle it
    >>differently (think index.html.sv, index.html.zh, index.php, etc).
    >
    >
    > From the web *browser*'s point of view, it is handled by the
    > "filesystem" (which is provided by the various servers). The browser
    > doesn't care how or where the data is stored. It just requests a file,
    > and gets some data back. So the browser doesn't have to check for
    > http://www.example.com/, get a failure (trying to read a directory),
    > check for http://www.example.com/index.html, etc. In this way, the web
    > server controls (which I think takes the place of the filesystem in this
    > case) what gets shown (index.html.sv, etc.), instead of the leaving it
    > up to the browser.

    Somewhat flawed analogy, though. After the protocol definition, the
    browser proper will take any URL that the protocol handler likes, which
    is why file:// works. After the domain, the http/https handler will
    take any URL at all, except for maybe some character set issues. So
    assuming the server is compatible with itself, we don't have to worry
    about whether the browser supports going to a directory and having it
    behave as a file (index.html behavior), or going to a file and having it
    behave as a directory (as some scripts do -- I've seen urls that look
    like http://example.com/foo.cgi/bar.html)

    Among protocols that behave more like filesystems, such as FTP, you
    can't really pull the same tricks. When an FTP client asks for a
    directory, it's probably asking for a directory listing, and would be
    quite surprised to find a file there -- or the user would when binary
    data floods their terminal.

    I *think* this is how FTP works, but I haven't used it in years, except
    through a web browser. I still get the feeling that even a web browser
    expects an FTP file to behave as a file and an FTP directory to behave
    as a directory.

    But I'm also pretty sure that FTP would be much more receptive to
    file-as-directory than your average sysadmin would. For one, breaking
    tar is unforgivable, and the only ways I can think of fixing that issue
    are shaky at best when you consider how many apps might do things
    oh-so-slightly different than tar.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Vojtech Pavlik: "Re: [PATCH] deinline sleep/delay functions"

    Relevant Pages

    • RE: [Full-Disclosure] How big is the danger of IE?
      ... The following link details compromised/malicious web servers infecting ... the web server configuration to append the script to all files served by ... method used to compromise the servers. ... switching to another browser may significantly reduce ...
      (Full-Disclosure)
    • RE: [Full-Disclosure] How big is the danger of IE?
      ... The following link details compromised/malicious web servers infecting ... the web server configuration to append the script to all files served by ... method used to compromise the servers. ... switching to another browser may significantly reduce ...
      (Full-Disclosure)
    • Re: ampersand in urls when using xhtml 1.0 strict
      ... My web server is clearly seeing & and the browser is ... After including this header I was able to remove the encoded ... First, this is very strange because if your browser was displaying the page as HTML, then it was already receiving a content type header from the web server telling it that the page was HTML, or else there was no header and the browser was treating it as HTML by default. ...
      (comp.infosystems.www.authoring.html)
    • [NT] Poisoning Cached HTTPS Documents in Internet Explorer
      ... Get your security news from a reliable source. ... "poison" a user's browser cache with a malicious document that will later ... The attacker can exploit this vulnerability for "replacing" HTML ... to communicate with a malicious web server over HTTPS without the browser ...
      (Securiteam)
    • Re: Control referring domain, another HTTP_REFERER option?
      ... If you trust the user's browser, ... so they could share a database, the referring web server could leave ... Cookies are designed not to work that way. ...
      (comp.lang.php)