Radio Buttons & Hyperlinks?

Discussion in 'HTML' started by Cerebral Believer, Sep 24, 2006.

  1. Anyone know if it is possible to use one hyperlink and a selection of radio
    buttons to send a person to a particular page depending on what radio button
    they check, eg.

    Please Choose A Format

    [a] <--- radio buttons

    CLICK HERE <-- hyperlink

    They would need to check one button, so the page should return with an error
    saying (please select a format), or send the user to a default page if no
    option is selected.

    Would appreciate some sample code if anyone has the time and inclination.

    Regards,
    C.B.
    Cerebral Believer, Sep 24, 2006
    #1
    1. Advertising

  2. Cerebral Believer wrote:
    > Anyone know if it is possible to use one hyperlink and a selection of radio
    > buttons to send a person to a particular page depending on what radio button
    > they check, eg.
    >
    > Please Choose A Format
    >
    > [a] <--- radio buttons
    >
    > CLICK HERE <-- hyperlink
    >
    > They would need to check one button, so the page should return with an error
    > saying (please select a format), or send the user to a default page if no
    > option is selected.
    >


    What would make this approach preferable to

    Read the specs in _Format A_ or _Format B_.

    where the underscore delimiters represent the beginning and end of
    hyperlinks?
    Harlan Messinger, Sep 24, 2006
    #2
    1. Advertising

  3. Cerebral Believer

    Toby Inkster Guest

    Cerebral Believer wrote:

    > Anyone know if it is possible to use one hyperlink and a selection of radio
    > buttons to send a person to a particular page depending on what radio button
    > they check


    It's certainly possible with a bit of Javascript attached to the "onclick"
    event of the hyperlink, but there are probably better ways of allowing the
    user to select between two different formats.

    One method might be to use a submit button to submit the radio button
    selection. A bit of CSS could style this to look almost exactly like a
    regular link.

    A better method might be to abandon the radio buttons altogether. If you
    simply want to offer a choice between two different formats, you could use
    two different links:

    <ul>
    <li><a href="high/">Broadband version</a></li>
    <li><a href="low/">Dial-up version</a></li>
    </ul>

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me ~ http://tobyinkster.co.uk/contact
    Toby Inkster, Sep 24, 2006
    #3
  4. Cerebral Believer

    richard Guest

    "Cerebral Believer" <> wrote in message
    news:ZrtRg.37607$...
    > Anyone know if it is possible to use one hyperlink and a selection of
    > radio buttons to send a person to a particular page depending on what
    > radio button they check, eg.
    >
    > Please Choose A Format
    >
    > [a] <--- radio buttons
    >
    > CLICK HERE <-- hyperlink
    >
    > They would need to check one button, so the page should return with an
    > error saying (please select a format), or send the user to a default page
    > if no option is selected.
    >
    > Would appreciate some sample code if anyone has the time and inclination.
    >
    > Regards,
    > C.B.


    Yes it can be done but not without some type of scripting.
    Because html would not know what to do with the clicks, let alone the
    buttons.
    Html is purely for presentation.
    richard, Sep 24, 2006
    #4
  5. Cerebral Believer

    Toby Inkster Guest

    richard wrote:

    > Html is purely for presentation.


    No -- CSS is purely for presentation.

    HTML is purely for structured content.

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me ~ http://tobyinkster.co.uk/contact
    Toby Inkster, Sep 25, 2006
    #5
  6. "Harlan Messinger" <> wrote in message
    news:...
    > Cerebral Believer wrote:
    >> Anyone know if it is possible to use one hyperlink and a selection of
    >> radio buttons to send a person to a particular page depending on what
    >> radio button they check, eg.
    >>
    >> Please Choose A Format
    >>
    >> [a] <--- radio buttons
    >>
    >> CLICK HERE <-- hyperlink
    >>
    >> They would need to check one button, so the page should return with an
    >> error saying (please select a format), or send the user to a default page
    >> if no option is selected.
    >>

    >
    > What would make this approach preferable to
    >
    > Read the specs in _Format A_ or _Format B_.
    >
    > where the underscore delimiters represent the beginning and end of
    > hyperlinks?


    Yes I agree I wasn't thinking straight. Actually I had been thinking of
    having page A where the choice is made, leading onto page B where someone
    gets use the format chosen, but I guess this is inefficient, and would
    involve using two pages for the same content which could be held on one
    page.

    Regards,
    C.B.
    Cerebral Believer, Sep 25, 2006
    #6
  7. Hi Toby,

    I chose to re-think what I was doing a little after reading the responses
    here. I am using FrontPage plus my own efforts to modify some of the code.
    I have a page at
    http://futurebydesign-music.com/_music/Future By Design/Long Journey Home Listen.htm -
    which is a page in progress, on a site in progress. This is what I have
    done so far and is my first effort at using FrontPage.

    The problem I have is that some of the images I am using do not show up,
    they are used as links to streaming audio files, and although the files
    reside in exactly the same directory as some other image files I am using on
    this page, and the HTML code seems to be correct, but they are not
    displaying (I checked they are on the server too). The images do show in
    preview mode in FrontPage though, so I am wondering if my CSS has introduced
    a conflict somehow which prevents the images from showing?

    Here is part of my HTML

    <td class="valtop">

    <a class="lisbut" onmouseover="document.getElementById('trk1m').src =
    '../../images/listenbuy/mp3_mo.jpg';"
    onmouseout="document.getElementById('trk1m').src =
    '../../images/listenbuy/mp3.jpg';"
    href="../../musdir/001Rs/Smooth%20Groove.m3u" type="audio/x-mpegurl">
    <img class="lisbut" id='trk1m' src="../../images/listenbuy/mp3.jpg"
    alt="Smooth Groove (.mp3)"></a>

    <a class="lisbut" onmouseover="document.getElementById('trk1r').src =
    '../../images/listenbuy/ra_mo.jpg';"
    onmouseout="document.getElementById('trk1r').src =
    '../../images/listenbuy/ra.jpg';"
    href="../../musdir/001Rs/Smooth%20Groove.ram" type="audio/x-pn-realaudio">
    <img class="lisbut" id='trk1r' src="../../images/listenbuy/ra.jpg"
    alt="Smooth Groove(.ra)"></a>

    <br>

    <a type="audio/x-mpegurl" title="Listen to the .mp3 sample of this track"
    href="../../musdir/001Rs/Smooth%20Groove.m3u">mp3</a>&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;

    <a title="Listen to the .ra sample of this track"
    href="../../musdir/Smooth%20Groove.ram">real</a><br/></td>

    </tr>

    The relevant CSS is:

    ..valtop {
    vertical-align: top;
    text-align: center;
    }
    ..lisbut {
    border: 1.5px solid #000000;
    }

    Maybe I will not use CSS to align my images, perhaps it was wrong to use
    text-align but instead I should have used a div or <p align="center"> tag.
    What are your thoughts on this and the design in general.

    Regards,
    C.B.

    "Toby Inkster" <> wrote in message
    news:5n.co.uk...
    > Cerebral Believer wrote:
    >
    >> Anyone know if it is possible to use one hyperlink and a selection of
    >> radio
    >> buttons to send a person to a particular page depending on what radio
    >> button
    >> they check

    >
    > It's certainly possible with a bit of Javascript attached to the "onclick"
    > event of the hyperlink, but there are probably better ways of allowing the
    > user to select between two different formats.
    >
    > One method might be to use a submit button to submit the radio button
    > selection. A bit of CSS could style this to look almost exactly like a
    > regular link.
    >
    > A better method might be to abandon the radio buttons altogether. If you
    > simply want to offer a choice between two different formats, you could use
    > two different links:
    >
    > <ul>
    > <li><a href="high/">Broadband version</a></li>
    > <li><a href="low/">Dial-up version</a></li>
    > </ul>
    >
    > --
    > Toby A Inkster BSc (Hons) ARCS
    > Contact Me ~ http://tobyinkster.co.uk/contact
    >
    Cerebral Believer, Sep 25, 2006
    #7
  8. No worries I fixed this. The new image files I added carried the .JPG
    extension, instead of .jpg, and that made all the difference!


    "Cerebral Believer" <> wrote in message
    news:7qMRg.32968$...
    > Hi Toby,
    >
    > I chose to re-think what I was doing a little after reading the responses
    > here. I am using FrontPage plus my own efforts to modify some of the
    > code. I have a page at
    > http://futurebydesign-music.com/_music/Future By Design/Long Journey Home Listen.htm -
    > which is a page in progress, on a site in progress. This is what I have
    > done so far and is my first effort at using FrontPage.
    >
    > The problem I have is that some of the images I am using do not show up,
    > they are used as links to streaming audio files, and although the files
    > reside in exactly the same directory as some other image files I am using
    > on this page, and the HTML code seems to be correct, but they are not
    > displaying (I checked they are on the server too). The images do show in
    > preview mode in FrontPage though, so I am wondering if my CSS has
    > introduced a conflict somehow which prevents the images from showing?
    >
    > Here is part of my HTML
    >
    > <td class="valtop">
    >
    > <a class="lisbut" onmouseover="document.getElementById('trk1m').src =
    > '../../images/listenbuy/mp3_mo.jpg';"
    > onmouseout="document.getElementById('trk1m').src =
    > '../../images/listenbuy/mp3.jpg';"
    > href="../../musdir/001Rs/Smooth%20Groove.m3u" type="audio/x-mpegurl">
    > <img class="lisbut" id='trk1m' src="../../images/listenbuy/mp3.jpg"
    > alt="Smooth Groove (.mp3)"></a>
    >
    > <a class="lisbut" onmouseover="document.getElementById('trk1r').src =
    > '../../images/listenbuy/ra_mo.jpg';"
    > onmouseout="document.getElementById('trk1r').src =
    > '../../images/listenbuy/ra.jpg';"
    > href="../../musdir/001Rs/Smooth%20Groove.ram" type="audio/x-pn-realaudio">
    > <img class="lisbut" id='trk1r' src="../../images/listenbuy/ra.jpg"
    > alt="Smooth Groove(.ra)"></a>
    >
    > <br>
    >
    > <a type="audio/x-mpegurl" title="Listen to the .mp3 sample of this track"
    > href="../../musdir/001Rs/Smooth%20Groove.m3u">mp3</a>&nbsp;&nbsp;&nbsp;-&nbsp;&nbsp;
    >
    > <a title="Listen to the .ra sample of this track"
    > href="../../musdir/Smooth%20Groove.ram">real</a><br/></td>
    >
    > </tr>
    >
    > The relevant CSS is:
    >
    > .valtop {
    > vertical-align: top;
    > text-align: center;
    > }
    > .lisbut {
    > border: 1.5px solid #000000;
    > }
    >
    > Maybe I will not use CSS to align my images, perhaps it was wrong to use
    > text-align but instead I should have used a div or <p align="center"> tag.
    > What are your thoughts on this and the design in general.
    >
    > Regards,
    > C.B.
    >
    > "Toby Inkster" <> wrote in message
    > news:5n.co.uk...
    >> Cerebral Believer wrote:
    >>
    >>> Anyone know if it is possible to use one hyperlink and a selection of
    >>> radio
    >>> buttons to send a person to a particular page depending on what radio
    >>> button
    >>> they check

    >>
    >> It's certainly possible with a bit of Javascript attached to the
    >> "onclick"
    >> event of the hyperlink, but there are probably better ways of allowing
    >> the
    >> user to select between two different formats.
    >>
    >> One method might be to use a submit button to submit the radio button
    >> selection. A bit of CSS could style this to look almost exactly like a
    >> regular link.
    >>
    >> A better method might be to abandon the radio buttons altogether. If you
    >> simply want to offer a choice between two different formats, you could
    >> use
    >> two different links:
    >>
    >> <ul>
    >> <li><a href="high/">Broadband version</a></li>
    >> <li><a href="low/">Dial-up version</a></li>
    >> </ul>
    >>
    >> --
    >> Toby A Inkster BSc (Hons) ARCS
    >> Contact Me ~ http://tobyinkster.co.uk/contact
    >>

    >
    >
    Cerebral Believer, Sep 26, 2006
    #8
  9. Cerebral Believer wrote:
    > No worries I fixed this. The new image files I added carried the .JPG
    > extension, instead of .jpg, and that made all the difference!
    >


    Something the Windows user must always be aware if is that unlike
    Windows most webservers are not on Windows platforms and filenames and
    paths are case-sensitive. The domain name is only where you can be lax
    because they are not case-sensitive.

    I recommend any Windows users that want to do any significant amount of
    web site development to find an old computer and slap together a LAMP
    server and do your development there rather than with local files. Will
    save you much debug frustration....

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Sep 26, 2006
    #9
  10. On Tue, 26 Sep 2006, Jonathan N. Little wrote:

    > Something the Windows user must always be aware if is that unlike
    > Windows most webservers are not on Windows platforms and filenames
    > and paths are case-sensitive. The domain name is only where you can
    > be lax because they are not case-sensitive.


    Well, yes, but I'd say that's putting the cart before the horse. URLs
    are by definition case-sensitive, and that's got nothing to do with
    the particular file system used on any specific server. It just so
    happens that when URLs are mapped to files on a Windows server, then
    typically two different URLs which differ only in their case are
    mapped to the same file i.e although the URLs are different, they
    access the same resource.

    It's not a good idea to rely on this - one should be consistent.

    > I recommend any Windows users that want to do any significant amount
    > of web site development to find an old computer and slap together a
    > LAMP server and do your development there rather than with local
    > files. Will save you much debug frustration....


    You make a good point. For most purposes, I'd recommend Windows users
    to install Win32 Apache locally, and use that for browsing their
    development site. There's far too many shortcomings involved in
    browsing files directly, without a server. But in regard to case
    sensitivity, it's going to have the same issues as we are discussing.
    Alan J. Flavell, Sep 26, 2006
    #10
  11. Alan J. Flavell wrote:
    > On Tue, 26 Sep 2006, Jonathan N. Little wrote:
    >
    >> Something the Windows user must always be aware if is that unlike
    >> Windows most webservers are not on Windows platforms and filenames
    >> and paths are case-sensitive. The domain name is only where you can
    >> be lax because they are not case-sensitive.

    >
    > Well, yes, but I'd say that's putting the cart before the horse. URLs
    > are by definition case-sensitive, and that's got nothing to do with
    > the particular file system used on any specific server. It just so
    > happens that when URLs are mapped to files on a Windows server, then
    > typically two different URLs which differ only in their case are
    > mapped to the same file i.e although the URLs are different, they
    > access the same resource.


    I would argue that you are incorrect. URLs are not *always*
    case-sensitive and case-sensitivity *is* platform dependent. Domain
    names are host names and are *not* case-sensitive yet a domain names can
    be a valid URL so:

    http://www.example.com
    http://WWW.EXAMPLE.COM
    http://wWw.eXaMpLe.cOm

    are all valid and equivalent URLs regardless of the server platform

    Where the trouble lies is with the path and file name part of the URL
    and as the w3.org states: "URLs in general are case-sensitive (with the
    exception of machine names)."

    http://www.w3.org/TR/WD-html40-970708/htmlweb.html

    I have yet to come across a IIS that won't parse:

    http://www.example.com/somepath/somefile.ext
    http://www.example.com/SOMEPATH/SOMEFILE.EXT
    http://www.example.com/somepath/somefile.EXT
    http://www.example.com/SOMEpath/somefile.ext
    http://www.example.com/sOmEpAtH/sOmEfIlE.eXt

    as equivalent so I would argue that case-sensitivity is server platform
    dependent.

    >
    > It's not a good idea to rely on this - one should be consistent.
    >
    >> I recommend any Windows users that want to do any significant amount
    >> of web site development to find an old computer and slap together a
    >> LAMP server and do your development there rather than with local
    >> files. Will save you much debug frustration....

    >
    > You make a good point. For most purposes, I'd recommend Windows users
    > to install Win32 Apache locally, and use that for browsing their
    > development site. There's far too many shortcomings involved in
    > browsing files directly, without a server. But in regard to case
    > sensitivity, it's going to have the same issues as we are discussing.


    I have never installed Apache on Windows, but as with other platform
    independent software like Perl, case does not matter on Windows but will
    on *nixes. I would say building a Linux box would be preferable because
    it would force you to be case-aware and your site would work regardless
    of the public web server...barring server-side scripting of course if
    your doing ASP!

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Sep 26, 2006
    #11
  12. Jonathan N. Little wrote:

    [snip]

    > URLs are not *always* case-sensitive


    Unless explicitly defined otherwise by the scheme, most URI components
    are assumed to case-sensitive. The scheme and host components are a
    special case. See section 6.2.2.1 in RFC 3986.

    > and case-sensitivity *is* platform dependent.


    Whether the mapping of URIs to the file system is case-sensitive or not
    is platform-dependent, yes, but that's irrelevant to whether URIs
    themselves are case-sensitive.

    [snip]

    > I have yet to come across a IIS that won't parse:
    >
    > http://www.example.com/somepath/somefile.ext
    > http://www.example.com/SOMEPATH/SOMEFILE.EXT
    > http://www.example.com/somepath/somefile.EXT
    > http://www.example.com/SOMEpath/somefile.ext
    > http://www.example.com/sOmEpAtH/sOmEfIlE.eXt
    >
    > as equivalent so I would argue that case-sensitivity is server
    > platform dependent.


    Check your browser cache. You should find separate entries for each one
    (I do).

    It doesn't matter that the server returns precisely the same response:
    even after case normalisation (which usually affects only the scheme,
    host, and percent-encoding), the URIs will be considered different when
    a comparison is made because they /are/ different (certainly so under HTTP).

    > I would say building a Linux box would be preferable because it would
    > force you to be case-aware ...


    I would recommend a much simpler approach: make sure that all resources
    use lower-case names, and write lower-case URIs.

    Mike
    Michael Winter, Sep 26, 2006
    #12
  13. On Tue, 26 Sep 2006, Jonathan N. Little wrote:

    > Alan J. Flavell wrote:


    > > URLs are by definition case-sensitive, and that's got nothing to
    > > do with the particular file system used on any specific server.


    > I would argue that you are incorrect. URLs are not *always* case-sensitive


    As you have pointed out, the host name part is not case-sensitive,
    that's true.

    > and case-sensitivity *is* platform dependent.


    No, that's wrong.

    > Domain names are host names and are
    > *not* case-sensitive yet a domain names can be a valid URL so:
    >
    > http://www.example.com
    > http://WWW.EXAMPLE.COM
    > http://wWw.eXaMpLe.cOm
    >
    > are all valid and equivalent URLs regardless of the server platform


    Accepted, but this is a distraction from the important point...

    > Where the trouble lies is with the path and file name part of the
    > URL and as the w3.org states: "URLs in general are case-sensitive
    > (with the exception of machine names)."


    Fine by me.

    > http://www.w3.org/TR/WD-html40-970708/htmlweb.html
    >
    > I have yet to come across a IIS that won't parse:
    >
    > http://www.example.com/somepath/somefile.ext
    > http://www.example.com/SOMEPATH/SOMEFILE.EXT
    > http://www.example.com/somepath/somefile.EXT
    > http://www.example.com/SOMEpath/somefile.ext
    > http://www.example.com/sOmEpAtH/sOmEfIlE.eXt
    >
    > as equivalent so I would argue that case-sensitivity is server platform
    > dependent.


    Those are all different URLs, by definition. If you used them - even
    assuming that the web server delivers the same content for all of them
    - they would all have to be cached separately by browsers,
    intermediate caches, etc.

    > I have never installed Apache on Windows, but as with other platform
    > independent software like Perl, case does not matter on Windows but

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > will on *nixes.


    Again this is wrong as stated. If I'm running e.g a CGI script on my
    Win32 Apache, then the script will see the actual URL that was
    presented, case and all, and can act accordingly. The distinction
    between differently-cased URLs disappears when the typical win32
    server maps URLs into the *file system*, it's true, but that's not
    because the URLs have magically become case-insensitive, but because
    the *file system* is, for these purposes, case-insensitive. The web
    doesn't know that, nor care about such internal server details -
    that's an important principle: URLs define a hierarchy of their own,
    which was designed to be server-agnostic.

    And note also what it says in
    http://httpd.apache.org/docs/2.2/platform/windows.html#cust
    about case-sensitivity in configuration directives for Win32 Apache.

    <aside>
    One *could* implement a Windows server in such a way that mis-cased
    URLs were redirected (301 would be good) to its canonically-cased URL,
    from which the resource would then be retrieved. This could relieve
    the problem of multiple URLs which all retrieve the same resource.
    But at the cost of an additional network transaction for mis-cased
    URLs.
    </>
    Alan J. Flavell, Sep 26, 2006
    #13
  14. Cerebral Believer

    Toby Inkster Guest

    Jonathan N. Little wrote:

    > http://www.example.com/somepath/somefile.ext
    > http://www.example.com/SOMEPATH/SOMEFILE.EXT
    > http://www.example.com/somepath/somefile.EXT
    > http://www.example.com/SOMEpath/somefile.ext
    > http://www.example.com/sOmEpAtH/sOmEfIlE.eXt


    These are all different URLs -- it doesn't matter what the server platform
    is. It just so happens, that a Windows server will return the same text to
    the browser in each case.

    But that's no different to:

    http://example.org/foo.txt
    http://example.com/bar.txt

    which are also different URLs, but might (by co-incidence or design)
    happen to contain identical text.

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me ~ http://tobyinkster.co.uk/contact
    Toby Inkster, Sep 26, 2006
    #14
  15. Alan J. Flavell wrote:

    > Again this is wrong as stated. If I'm running e.g a CGI script on my
    > Win32 Apache, then the script will see the actual URL that was
    > presented, case and all, and can act accordingly. The distinction
    > between differently-cased URLs disappears when the typical win32
    > server maps URLs into the *file system*, it's true, but that's not
    > because the URLs have magically become case-insensitive, but because
    > the *file system* is, for these purposes, case-insensitive. The web
    > doesn't know that, nor care about such internal server details -
    > that's an important principle: URLs define a hierarchy of their own,
    > which was designed to be server-agnostic.


    It may be semantics here, and that the HTTP transaction will be
    case-sensitive and it is the mapping file system case-insensitive
    occurs. The file system does come to play here though. Yes your can
    configure the web server to compensate, but I have really come across
    any. In practice then the server is on a Windows platform and URIs sent
    to the server in different case combinations, the web server may treat
    as unique resources to fetch. The browser may (does) cache as unique
    resources. But the Windows file systems will not fetch difference
    resource is will all be the same file. So the "appearance" is that on
    Windows platforms the URI may "seem" case-insensitive which can lull
    less-savvy web designer to make errors that make their site not platform
    independent.


    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Sep 26, 2006
    #15
  16. Toby Inkster wrote:
    > Jonathan N. Little wrote:
    >
    >> http://www.example.com/somepath/somefile.ext
    >> http://www.example.com/SOMEPATH/SOMEFILE.EXT
    >> http://www.example.com/somepath/somefile.EXT
    >> http://www.example.com/SOMEpath/somefile.ext
    >> http://www.example.com/sOmEpAtH/sOmEfIlE.eXt

    >
    > These are all different URLs -- it doesn't matter what the server platform
    > is. It just so happens, that a Windows server will return the same text to
    > the browser in each case.
    >
    > But that's no different to:
    >
    > http://example.org/foo.txt
    > http://example.com/bar.txt
    >
    > which are also different URLs, but might (by co-incidence or design)
    > happen to contain identical text.
    >

    But is not in the first instance a matter of indiscrimination of the
    platform's files system and in the second by configuration of the web
    server?

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
    Jonathan N. Little, Sep 26, 2006
    #16
  17. Cerebral Believer

    Toby Inkster Guest

    Jonathan N. Little wrote:

    > But is not in the first instance a matter of indiscrimination of the
    > platform's files system and in the second by configuration of the web
    > server?


    As far as the client is concerned, what's the difference?

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me ~ http://tobyinkster.co.uk/contact
    Toby Inkster, Sep 26, 2006
    #17
  18. Cerebral Believer

    Toby Inkster Guest

    Jonathan N. Little wrote:

    > It may be semantics here, and that the HTTP transaction will be
    > case-sensitive and it is the mapping file system case-insensitive
    > occurs. The file system does come to play here though. Yes your can
    > configure the web server to compensate, but I have really come across
    > any.


    http://www.nct.org.uk/info/Cot_Death/FSiD
    versus
    http://www.nct.org.uk/info/Cot_Death/FSID

    Windows 2000, Apache 2.0.x.

    I didn't take any special measures to "compensate" for the file system's
    case-insensitivity -- it's simply that the file system is barely even
    *used* to serve this page -- it comes from a (case-sensitive) SQL database.

    --
    Toby A Inkster BSc (Hons) ARCS
    Contact Me ~ http://tobyinkster.co.uk/contact
    Toby Inkster, Sep 26, 2006
    #18
  19. On Tue, 26 Sep 2006, Jonathan N. Little wrote:

    > Alan J. Flavell wrote:
    >
    > > [...] The distinction between differently-cased URLs disappears
    > > when the typical win32 server maps URLs into the *file system*,
    > > it's true, but that's not because the URLs have magically become
    > > case-insensitive, but because the *file system* is, for these
    > > purposes, case-insensitive. The web doesn't know that, nor care
    > > about such internal server details - that's an important
    > > principle: URLs define a hierarchy of their own, which was
    > > designed to be server-agnostic.

    >
    > It may be semantics here, and that the HTTP transaction will be
    > case-sensitive and it is the mapping file system case-insensitive
    > occurs.


    As several other contributors have also pointed out: URLs are, by
    definition, case-sensitive. You can't argue that away (if that's what
    you were trying to do). It's an important principle, as I said, that
    the URL scheme was defined to be server-agnostic: the web does not
    know, and does not need to know, these details about a server, any
    more than it would need to have the "/" replaced by ":" or "\"
    depending on details of the server's file system.

    > The file system does come to play here though. Yes your can
    > configure the web server to compensate, but I have really come
    > across any.


    I think you missed a negative there, but this is an important
    principle, and applies irrespective of whether you or I have seen
    examples of it actually being done.

    This is rather a fundamental principle of the web architecture - it's
    not just an argument about "counting angels on pinheads", which is why
    I'm still dragging this argument out as long as you seem to be
    obscuring the principle. Sorry.
    Alan J. Flavell, Sep 27, 2006
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?SXJmYW4gQWtyYW0=?=

    Hyperlinks vs Buttons ?

    =?Utf-8?B?SXJmYW4gQWtyYW0=?=, Feb 13, 2005, in forum: ASP .Net
    Replies:
    5
    Views:
    594
    =?Utf-8?B?SXJmYW4gQWtyYW0=?=
    Feb 13, 2005
  2. Alexander Weiner

    using hyperlinks as submit buttons

    Alexander Weiner, Jun 27, 2006, in forum: HTML
    Replies:
    13
    Views:
    921
    Alan J. Flavell
    Jul 2, 2006
  3. Scott D Johnson
    Replies:
    1
    Views:
    1,065
    Scott D Johnson
    Sep 27, 2006
  4. Dr. Leff
    Replies:
    3
    Views:
    290
    David Mark
    Oct 15, 2007
  5. Dr. Leff
    Replies:
    3
    Views:
    226
    David Mark
    Oct 15, 2007
Loading...

Share This Page