Exact match. Not showing close matches.
PICList
Thread
'[EE] Roman Black is allive and is designing clocks'
2008\05\25@124938
by
Vasile Surducan
www.romanblack.com/binclk.htm
2008\05\25@150839
by
Cedric Chang
2008\05\25@153559
by
Peter Todd
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, May 25, 2008 at 09:49:13AM -0700, Vasile Surducan wrote:
> http://www.romanblack.com/binclk.htm
Is it just me or are the images broken? :(
- --
http://petertodd.org 'peter'[:-1]@petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIOb9+3bMhDbI9xWQRAopHAJ4uulWViV78gUYevdraIHLvlLqZ5QCfU36O
hSqrJ/dqD1rsbM2h/I11Ftc=
=ZAqj
-----END PGP SIGNATURE-----
2008\05\25@160641
by
Richard Prosser
It's not just you.
RP
2008/5/26 Peter Todd <spam_OUTpeteTakeThisOuT
petertodd.org>:
{Quote hidden}> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun, May 25, 2008 at 09:49:13AM -0700, Vasile Surducan wrote:
>>
http://www.romanblack.com/binclk.htm
>
> Is it just me or are the images broken? :(
>
> - --
>
http://petertodd.org 'peter'[:-1]@petertodd.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIOb9+3bMhDbI9xWQRAopHAJ4uulWViV78gUYevdraIHLvlLqZ5QCfU36O
> hSqrJ/dqD1rsbM2h/I11Ftc=
> =ZAqj
> -----END PGP SIGNATURE-----
> -
2008\05\25@175650
by
Gerhard Fiedler
2008\05\25@180510
by
Richard Prosser
2008\05\25@184138
by
John Coppens
On Mon, 26 May 2008 10:04:45 +1200
"Richard Prosser" <rhprosserKILLspamgmail.com> wrote:
> Looks like that's it - it does comes up fine in IE.
Also works with Opera on Linux, not with FF.
John
2008\05\25@185856
by
Brian B. Riley
It also comes up fine in Mac OS X Safari
cheers ... BBR
On May 25, 2008, at 6:04 PM, Richard Prosser wrote:
{Quote hidden}
> --
2008\05\25@191857
by
Dave Tweed
|
Gerhard Fiedler wrote:
> Peter Todd wrote:
>
> > On Sun, May 25, 2008 at 09:49:13AM -0700, Vasile Surducan wrote:
> > > http://www.romanblack.com/binclk.htm
> >
> > Is it just me or are the images broken? :(
>
> It seems Firefox can't handle encoded URLs.
No, Firefox "handles" encoded URLs just fine.
> I can get to the images by copying the image location, say
> "http://www.romanblack.com/.%5Cbinclock%5Cbinclk01.gif" and replacing
> "%5C" with "/". This then becomes
> "http://www.romanblack.com/./binclock/binclk01.gif", which works.
BUT ... 0x5C isn't '/', it's '\'.
'/' is 0x2F.
The problem is that Roman has used '\' as the path separator his image
URLs, which probably works just fine when he tests it on his local
(Windows) machine. However, the web server from which he's serving the
images to the rest of us doesn't like it.
> FWIW, IE decodes the image URLs correctly and displays the images.
Firefox is being "strict" and using the URL exactly as presented ... as it
should, really.
However, this problem is so prevalent that other browsers, such as IE and
Opera, automatically translate '\' to '/' before sending a URL back to the
server, thereby hiding the underlying problem.
-- Dave Tweed
2008\05\25@204740
by
Apptech
> Very clever. I would alter it to display in 24 hour
> fashion.
>> http://www.romanblack.com/binclk.htm
24 hour add on is easy enough. Maybe a thin line full width
line somewhere.
While the 30/15 minute indicators are understandable where
they are they would make more logical sense if placed under
the hours indicators. Easily enough done, but would need a
change to the overall common shape in all schemes and so may
not be favoured by Roman.
Russell
2008\05\26@074827
by
Gerhard Fiedler
|
Dave Tweed wrote:
>> It seems Firefox can't handle encoded URLs.
>
> No, Firefox "handles" encoded URLs just fine.
>
>> I can get to the images by copying the image location, say
>> "http://www.romanblack.com/.%5Cbinclock%5Cbinclk01.gif" and replacing
>> "%5C" with "/". This then becomes
>> "http://www.romanblack.com/./binclock/binclk01.gif", which works.
>
> BUT ... 0x5C isn't '/', it's '\'.
>
> '/' is 0x2F.
Oh... missed that one :)
{Quote hidden}> The problem is that Roman has used '\' as the path separator his image
> URLs, which probably works just fine when he tests it on his local
> (Windows) machine. However, the web server from which he's serving the
> images to the rest of us doesn't like it.
>
>> FWIW, IE decodes the image URLs correctly and displays the images.
>
> Firefox is being "strict" and using the URL exactly as presented ... as
> it should, really.
>
> However, this problem is so prevalent that other browsers, such as IE
> and Opera, automatically translate '\' to '/' before sending a URL back
> to the server, thereby hiding the underlying problem.
... and making it work. I'm in general all for programs "making it work",
and consider this as "doing what it should, really" :)
Is there any disadvantage to the behavior of IE, Opera and the like?
Gerhard
2008\05\26@081241
by
sergio masci
|
On Mon, 26 May 2008, Gerhard Fiedler wrote:
{Quote hidden}> Dave Tweed wrote:
>
> >> It seems Firefox can't handle encoded URLs.
> >
> > No, Firefox "handles" encoded URLs just fine.
> >
> >> I can get to the images by copying the image location, say
> >> "
http://www.romanblack.com/.%5Cbinclock%5Cbinclk01.gif" and replacing
> >> "%5C" with "/". This then becomes
> >> "
http://www.romanblack.com/./binclock/binclk01.gif", which works.
> >
> > BUT ... 0x5C isn't '/', it's '\'.
> >
> > '/' is 0x2F.
>
> Oh... missed that one :)
>
> > The problem is that Roman has used '\' as the path separator his image
> > URLs, which probably works just fine when he tests it on his local
> > (Windows) machine. However, the web server from which he's serving the
> > images to the rest of us doesn't like it.
> >
> >> FWIW, IE decodes the image URLs correctly and displays the images.
> >
> > Firefox is being "strict" and using the URL exactly as presented ... as
> > it should, really.
> >
> > However, this problem is so prevalent that other browsers, such as IE
> > and Opera, automatically translate '\' to '/' before sending a URL back
> > to the server, thereby hiding the underlying problem.
>
> ... and making it work. I'm in general all for programs "making it work",
> and consider this as "doing what it should, really" :)
>
> Is there any disadvantage to the behavior of IE, Opera and the like?
Yes, '\' is treated as an escape character (treat next char or sequence of
chars as special) in many places. This could have security implications on
software running on the server.
Regards
Sergio Masci
2008\05\26@082151
by
Dave Tweed
|
|
Gerhard Fiedler <EraseMElistsspam_OUTTakeThisOuTconnectionbrazil.com>
> Dave Tweed wrote:
> > However, this problem is so prevalent that other browsers, such as IE
> > and Opera, automatically translate '\' to '/' before sending a URL back
> > to the server, thereby hiding the underlying problem.
>
> ... and making it work. I'm in general all for programs "making it work",
> and consider this as "doing what it should, really" :)
So, you're a "two wrongs make a right" and "the end justifies the means"
type of person?
> Is there any disadvantage to the behavior of IE, Opera and the like?
Well, obviously, it makes it impossible to send a backslash to the server
in the case where it really wants one. Maybe not a big deal in the grand
scheme of things, but it's definitely nonstandard and unexpected behavior.
I wonder if the browsers even give you the ability to turn that "feature"
off, and how long it takes to figure out how to do so.
Actually, if they're doing it right, they're making two requests -- one
with the backslashes as originally specified, and then only when that
fails, flipping them to forward slashes and trying again.
-- Dave Tweed
2008\05\26@082638
by
Wouter van Ooijen
>> However, this problem is so prevalent that other browsers, such as IE
>> and Opera, automatically translate '\' to '/' before sending a URL back
>> to the server, thereby hiding the underlying problem.
>
> ... and making it work. I'm in general all for programs "making it work",
> and consider this as "doing what it should, really" :)
>
> Is there any disadvantage to the behavior of IE, Opera and the like?
Yes: an error goes unnoticed.
The problem with "doing what it should, really" (as opposed to "doing
what it is instructed to do, literally") is that not everyone will agree
on what should be done.
Compare: I gave a big problem with the way Windows handles
uppper/lowercase file names. When a file is openend/created, it is
created as specified, *except when a file exist with the same name but
different case*, then that file is opened. So when I create a file I
can't be sure that a file with exactly that name will be created! Big
problem when I put image links in my html files to a file with *exactly*
that name.
--
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
2008\05\26@213353
by
Gerhard Fiedler
|
|
Wouter van Ooijen wrote:
>>> However, this problem is so prevalent that other browsers, such as IE
>>> and Opera, automatically translate '\' to '/' before sending a URL
>>> back to the server, thereby hiding the underlying problem.
>>
>> ... and making it work. I'm in general all for programs "making it
>> work", and consider this as "doing what it should, really" :)
>>
>> Is there any disadvantage to the behavior of IE, Opera and the like?
>
> Yes: an error goes unnoticed.
That's a problem for a web developer, not for a user. If a tool makes it
that web developers' errors go unnoticed, I'm all for it. Developers should
use different tools than the users (in addition to the same browsers, of
course) to check for errors. I expect that from a web developer (and for
example my browser settings are quite different when I'm checking a site
than when I'm visiting a site).
> The problem with "doing what it should, really" (as opposed to "doing
> what it is instructed to do, literally") is that not everyone will agree
> on what should be done.
We may not even have an agreement on what means "doing what it is
instructed to do, literally". I may think that it was instructed to get the
images embedded in that page. Some browsers managed to get them, others
didn't.
> Compare: I gave a big problem with the way Windows handles
> uppper/lowercase file names.
You shouldn't rely on anything related to the case of filenames on Windows.
Windows is by definition not file system case aware. If you have a problem
with that, you need to use a different OS (or a program that does what you
want on top of the Windows API). It's as simple as that. This is a
completely different issue. From your comments, it seems you want a
case-sensitive file system, and Windows doesn't have this -- by definition.
Gerhard
2008\05\26@214007
by
Gerhard Fiedler
|
|
sergio masci wrote:
>>> However, this problem is so prevalent that other browsers, such as IE
>>> and Opera, automatically translate '\' to '/' before sending a URL
>>> back to the server, thereby hiding the underlying problem.
>>
>> ... and making it work. I'm in general all for programs "making it
>> work", and consider this as "doing what it should, really" :)
>>
>> Is there any disadvantage to the behavior of IE, Opera and the like?
>
> Yes, '\' is treated as an escape character (treat next char or sequence of
> chars as special) in many places. This could have security implications on
> software running on the server.
How? What security implication could it have when a browser sends an http
request back to the server where %5C has been replaced with a _forward_
slash? The worst that should happen with any decent web server is that
either the document is not found or a wrong document is found. If either
has security implications with your server or site, you have other things
to worry about than a browser that replaces %5C with a slash.
Gerhard
2008\05\26@214506
by
Gerhard Fiedler
|
|
Dave Tweed wrote:
> Gerhard Fiedler <listsspam_OUTconnectionbrazil.com>
>> Dave Tweed wrote:
>>> However, this problem is so prevalent that other browsers, such as IE
>>> and Opera, automatically translate '\' to '/' before sending a URL back
>>> to the server, thereby hiding the underlying problem.
>>
>> ... and making it work. I'm in general all for programs "making it work",
>> and consider this as "doing what it should, really" :)
>
> So, you're a "two wrongs make a right" and "the end justifies the means"
> type of person?
I hope this was a joke without a smiley... There is no relationship to what
I wrote, and even if there were, it's quite a long shot to make assumptions
about my personality from one remark about what I expect from a program.
(In case someone wants to misinterpret this remark, it does not answer the
question.)
>> Is there any disadvantage to the behavior of IE, Opera and the like?
>
> Well, obviously, it makes it impossible to send a backslash to the
> server in the case where it really wants one.
That's the only disadvantage I could come up with, but I haven't seen a
file or directory name with a backslash in it so far. AFAIK, in the
position the backslash was in the URL in question it wouldn't have been a
legal backslash, at least not for
So I'm not sure whether this is really a disadvantage.
> Actually, if they're doing it right, they're making two requests -- one
> with the backslashes as originally specified, and then only when that
> fails, flipping them to forward slashes and trying again.
If they do that, is there a disadvantage left? (For the user, not for a web
developer -- a web developer can use whatever tool is adequate for checking
correctness.)
FWIW, what Firefox does is at least a bit odd. Take a normal, working URL
and replace a slash with %2F, for example
http://server/dir1/dir2%2Fdocument.ext. Chances are that you get an error
page back stating that "document /dir1/dir2/document.ext can't be found on
this server" -- knowing that document /dir1/dir2/document.ext does exist.
While formally correct, it's still odd for the unsuspecting user and not
really user-friendly.
Gerhard
2008\05\26@222125
by
Apptech
|
>>> Is there any disadvantage to the behavior of IE, Opera
>>> and the like?
>> Yes: an error goes unnoticed.
> That's a problem for a web developer, not for a user. If a
> tool makes it
> that web developers' errors go unnoticed, I'm all for it.
The problems can come from the implications of the
philosophy. In this case the adverse effects may usually be
minor - eg as noted, possible inability to pass an intended
"\".
BUT when a program starts "reading my brain", or somebody
else's, then if it gets it wrong the outcome can be anything
that the system is capable of doing. While one would hope
that such "interpretation" was suitably ring fenced with
precautions, but human nature, and programmers seem in no
way excluded from the general rule, is such that once you
let people do anything they occasionally will, regardless of
how bizarre the outcome. Having a standard that you think
you are working to gives more 9's protection against human
nature taking over. Allowing people to interpret the
standard when it seems like a good idea adds and subtracts
9's semi-randomly.
The Erebus DC10 crash was caused by a substantial series of
human actions, any one of which, had it been omitted. would
have not seen the aircraft go to its doom. At least one of
these involved a person reading somebody else's mind
incorrectly. Letting a person enable a computer to do it is
even more risky.
Russell
2008\05\26@225544
by
James Newton
2008\05\27@075846
by
Dave Tweed
|
|
Gerhard Fiedler wrote:
> Dave Tweed wrote:
> > Gerhard Fiedler wrote:
> > > ... and making it work. I'm in general all for programs "making it
> > > work", and consider this as "doing what it should, really" :)
> >
> > So, you're a "two wrongs make a right" and "the end justifies the means"
> > type of person?
>
> I hope this was a joke without a smiley... There is no relationship to
> what I wrote, and even if there were, it's quite a long shot to make
> assumptions about my personality from one remark about what I expect from
> a program.
Only partly. What exactly did you mean by your original comment?
If you're going to take this that seriously, then I will, too.
{Quote hidden}> >> Is there any disadvantage to the behavior of IE, Opera and the like?
> >
> > Well, obviously, it makes it impossible to send a backslash to the
> > server in the case where it really wants one.
>
> That's the only disadvantage I could come up with, but I haven't seen a
> file or directory name with a backslash in it so far. AFAIK, in the
> position the backslash was in the URL in question it wouldn't have been a
> legal backslash, at least not for
> So I'm not sure whether this is really a disadvantage.
You're making the assumption that the components of a URL always represent
directory and file names. Sure, 99% of the time they do, because most web
servers simply map a URL "path" directly onto a filesystem "path". However,
it's actually up to each web server to define exectly what anything
following the slash after the hostname actually means.
You're also assuming that anything that the webserver host OS accepts as a
filesystem path separator should also be legal as a URL path separator.
In HTTP, '\' is a "token separator" but not a path separator, except when
used within a quoted string, in which case it is a one-character esacape.
'/' is both a token separator and a path separator (but not inside a quoted
string).
> > Actually, if they're doing it right, they're making two requests -- one
> > with the backslashes as originally specified, and then only when that
> > fails, flipping them to forward slashes and trying again.
>
> If they do that, is there a disadvantage left? (For the user, not for a
> web developer -- a web developer can use whatever tool is adequate for
> checking correctness.)
Sure! Even if the feature is implemented this way, there needs to be a way
to turn it off.
> FWIW, what Firefox does is at least a bit odd. Take a normal, working URL
> and replace a slash with %2F, for example
> http://server/dir1/dir2%2Fdocument.ext. Chances are that you get an error
> page back stating that "document /dir1/dir2/document.ext can't be found on
> this server" -- knowing that document /dir1/dir2/document.ext does exist.
> While formally correct, it's still odd for the unsuspecting user and not
> really user-friendly.
Firefox's behavior is NOT odd. '\' is not a legal character in a URI (see
RFC2396), so a browser HAS to URL-encode it using the "% hex hex" syntax.
On the other hand, '/' is a "reserved" character in a URI, so it is a path
separator if it is not URL-encoded, but treated as an ordinary character
within a path element if it is encoded as %2F.
All of this is carefully spelled out in the RFCs. Any browser that plays
fast and loose with this stuff is headed into dangerous territory.
-- Dave Tweed
2008\05\27@091913
by
sergio masci
|
|
On Mon, 26 May 2008, Gerhard Fiedler wrote:
{Quote hidden}> sergio masci wrote:
>
> >>> However, this problem is so prevalent that other browsers, such as IE
> >>> and Opera, automatically translate '\' to '/' before sending a URL
> >>> back to the server, thereby hiding the underlying problem.
> >>
> >> ... and making it work. I'm in general all for programs "making it
> >> work", and consider this as "doing what it should, really" :)
> >>
> >> Is there any disadvantage to the behavior of IE, Opera and the like?
> >
> > Yes, '\' is treated as an escape character (treat next char or sequence of
> > chars as special) in many places. This could have security implications on
> > software running on the server.
>
> How? What security implication could it have when a browser sends an http
> request back to the server where %5C has been replaced with a _forward_
> slash? The worst that should happen with any decent web server is that
> either the document is not found or a wrong document is found. If either
> has security implications with your server or site, you have other things
> to worry about than a browser that replaces %5C with a slash.
Who said the browser is just replacing '\' with '/'? The browser is doing
what it wants to in order to try to resolve a problem with the '\'. Where
is the documentation that explicitly defines what each browser does in
order to resolve the problem?
The server doesn't just return pages of text or images in response to a
request to get a page or an image, it also runs small user apps (CGIs).
Sometimes a request for a page or image is not processed directly
by the server but through a CGI (kind of like a filter). Counters on web
pages are good examples of images generated by a CGI even though the
browser thinks it is asking for an image.
Sometimes a CGI will be set up to intercept access to a specific page. By
convention CGIs normally have filename extentions that make them stand
out. But this is not a hard and fast rule. The web server can easily be
configured to process CGIs with the filename extension .html. Amoungst
other things this helps admins that are having hacking problems hide their
CGIs. So the browser may actually be sending escape sequences back to a
CGI :-)
Another problem is that sometimes information sent by a browser to a
server is incorporated in subsequent web pages sent back to the browser by
the server (in a hidden form). The browser receives the page as a stream
of text and interprets it. If a hacker can cause a sequence of characters
to be inserted into the stream (as is the case by manipulating the hidden
information which was passed to the server in the first place) then the
hacker can change the web page he sees on his browser. Maybe he can insert
a button to bypass authentication or something. Then he would be able to
press the button on his browser and continue hacking away at your server.
You should see some of the attacks that people try on my server. For the
most part they are just long strings in the queries (and yes sometimes
they contain '\')
If you really want to investigate this further, try google, you'll find a
lot of unexpected stuff.
Regards
Sergio Masci
2008\05\27@103754
by
Gerhard Fiedler
|
|
Apptech wrote:
>>>> Is there any disadvantage to the behavior of IE, Opera and the like?
>
>>> Yes: an error goes unnoticed.
>
>> That's a problem for a web developer, not for a user. If a tool makes it
>> that web developers' errors go unnoticed, I'm all for it.
>
> The problems can come from the implications of the philosophy. In this
> case the adverse effects may usually be minor - eg as noted, possible
> inability to pass an intended "\".
Of course, there are problematic implications with this philosophy.
But WRT this specific case: if the browsers do what Dave suggests may
happen (try the specified path first, then, if fails, try the guessed path)
I fail to see how this could bring down a DC10. If it does, I suggest that
there are other problems with the design of the DC10.
Even if they don't do that, I wonder who will ever need to pass a backslash
in such a position in the path to a server. Anybody any real-world
examples? I asked what bad this /specific/ behavior would do, and the
answers range from ad hominem attacks to DC10 crashes... either
specifically strange, or not really very specific :)
And in the general case: there are problematic implications with any
philosophy. While it's of course possible to find scenarios where a guessed
user intention does harm, it's equally easy to find scenarios where this
does exactly what's needed. There may even be more such scenarios. I'd
guess that it is more often that a web developer puts a bad path in a page
that can be fixed by such guessing than that a web developer needs to pass
back a backslash in the path to the server. (Which, ironically enough, was
called a security risk by Sergio, trying to criticize the IE/Opera behavior
-- while in fact supporting it, if anything.)
> BUT when a program starts "reading my brain", or somebody else's, then if
> it gets it wrong the outcome can be anything that the system is capable
> of doing.
IMO a browser is not only a tool for techies to analyze and test sites, it
is at least as much an interface for non-technical users (who never have
heard about "RFC", wouldn't recognize one if they saw one and couldn't care
less about the fine details spelled out it them) who just want to browse
the (not always RFC and W3C compliant) web and see what they want to see.
They don't instruct their browser to "show me each error in any page you
get", they instruct it to "get me the page with everything so that I can
read it". A different approach that needs different UI behavior.
All good user interfaces "read my (the user's) brain" to some degree. It's
inevitable to occasionally get it wrong -- then the guess was just wrong,
but it could just as well be because of reading too much as because of
reading too little. We all know that users, in their overwhelming majority,
don't read manuals, so saying "it's behaving as written in the manual" when
it does something a user didn't expect is ingenuous at best (as a UI
designer). A UI designer always needs to try to "read the brain" of the
user, try to prevent anything that could yield disastrous results and try
to "get it right" as much as possible.
OTOH, in this specific case, it wasn't even the user's brain that was read,
it was transforming a wrong URL into a correct one. That's a fact...
Firefox (with only the RFC behavior) doesn't show the page as it is
intended, while some other browsers do. I asked what's wrong with this
specific "improvement", and the arguments... well, you saw them:
- Ad hominem attacks. Anybody who suggests this could be a good thing is a
"the end justifies the means" person (and probably willing to do anything
to get what he wants).
- Not possible to send a backslash to the server if one needs that. Two
things missing here: one is a good case for wanting to do so (I think in
10+ years I'm browsing the net I've never seen a case where a backslash has
been sent back to the server as part of the http path, on purpose) and the
other is that it's not clear whether the browsers that manage to display
the page as intended only send the guessed request after the "RFC correct"
but wrong request failed (which would completely invalidate this argument).
- Error goes unnoticed: This is exactly what the majority of users wants. I
don't want to be bothered by the errors of web developers when surfing. I'm
not checking their sites for errors, I want to read them.
- Security problems caused by backslashes sent to the server: I don't think
there is, but in any case this is something that is being prevented by this
behavior, not caused by it.
> While one would hope that such "interpretation" was suitably ring fenced
> with precautions, but human nature, and programmers seem in no way
> excluded from the general rule, is such that once you let people do
> anything they occasionally will, regardless of how bizarre the outcome.
> Having a standard that you think you are working to gives more 9's
> protection against human nature taking over. Allowing people to
> interpret the standard when it seems like a good idea adds and subtracts
> 9's semi-randomly.
This is very abstract and with little relationship to the actual case. I
think you see what I mean once you start applying this paragraph to the
case in question, in detail. It's not even clear that IE, Opera and the
others that manage to get it right do anything that's not conformant with
RFCs. (There is no RFC for user interfaces... and nowhere is written that
the browser's address line needs to go verbatim into the GET or POST line
of an http request. There's all kinds of magic between the browser's
address line and the http request that we're accustomed to, and Firefox is
no exception here. If you don't want the magic, get a web developer tool to
run "naked" http requests.) It's also quite unclear whether the behavior is
as specified (by the browser manufacturer) or not. If it is as specified,
this whole paragraph simply doesn't apply.
What's really surprising in this thread is how many unfounded assumptions
such a simple question can bring to light.
Gerhard
2008\05\27@112137
by
Gerhard Fiedler
|
|
sergio masci wrote:
>>> Yes, '\' is treated as an escape character (treat next char or sequence of
>>> chars as special) in many places. This could have security implications on
>>> software running on the server.
>>
>> How? What security implication could it have when a browser sends an http
>> request back to the server where %5C has been replaced with a _forward_
>> slash? The worst that should happen with any decent web server is that
>> either the document is not found or a wrong document is found. If either
>> has security implications with your server or site, you have other things
>> to worry about than a browser that replaces %5C with a slash.
>
> Who said the browser is just replacing '\' with '/'? The browser is
> doing what it wants to in order to try to resolve a problem with the
> '\'. Where is the documentation that explicitly defines what each
> browser does in order to resolve the problem?
I don't know where the documentation is. The question wasn't even about
replacing '\' with '/', it was about replacing "%5C" with "/", and about
what harm that does.
> So the browser may actually be sending escape sequences back to a
> CGI :-)
When sending _forward_ slashes? What escape sequences are you thinking
about?
> If a hacker can cause a sequence of characters to be inserted into the
> stream (as is the case by manipulating the hidden information which was
> passed to the server in the first place) then the hacker can change the
> web page he sees on his browser.
Of course. But any hacker can do that, independently of any browser
behavior. There are better tools than browsers for sending "custom" http
requests. Any telnet terminal does just fine.
> You should see some of the attacks that people try on my server. For the
> most part they are just long strings in the queries (and yes sometimes
> they contain '\')
You seem to miss consistently the point that IE, Opera and the others did
_not_ send back a backslash in the path. The guessed path contained a
_forward_ slash instead of the %5C string.
And it was not in the argument part after the question mark (where the
hackers like to place the backslash, because the applications interpreting
this part of the URL usually are less safe than the servers interpreting
the path).
> If you really want to investigate this further, try google, you'll find a
> lot of unexpected stuff.
Maybe, or maybe not... I guess you don't really know that well what I
expect to find, or what I know about this. And maybe I just do that -- if
you can show one specific (ideally real-world) example where replacing
"%5C" with "/" in a URL path is a security risk -- rather than some general
comments about CGI and URL hacking. (If anything, it's the Firefox behavior
that's a risk in the way you're saying: it allows you to send an encoded
backslash to the server. Where it's still not clear whether the others
don't allow you to do this.) Any site or server security that relies on
"correct URLs" is flawed from the start. If you want a secure site, it
needs to be secure with _any_ URL -- exactly because it's so easy to send
any URL to a site.
Gerhard
2008\05\27@112543
by
Gerhard Fiedler
|
|
Dave Tweed wrote:
> Gerhard Fiedler wrote:
>> Dave Tweed wrote:
>>> Gerhard Fiedler wrote:
>>> > ... and making it work. I'm in general all for programs "making it
>>> > work", and consider this as "doing what it should, really" :)
>>>
>>> So, you're a "two wrongs make a right" and "the end justifies the means"
>>> type of person?
>>
>> I hope this was a joke without a smiley... There is no relationship to
>> what I wrote, and even if there were, it's quite a long shot to make
>> assumptions about my personality from one remark about what I expect
>> from a program.
>
> Only partly.
What part then was not a joke? And what did you mean with that?
> What exactly did you mean by your original comment?
That some browsers display the page as intended, and some don't. As a web
user, I prefer it when a browser displays the page as intended, unless
there is a drawback in doing so. I asked whether anybody would know any
drawback to this specific behavior.
> If you're going to take this that seriously, then I will, too.
If the above was only "partly" a joke, you better should have taken it
seriously when you wrote it.
{Quote hidden}>>>> Is there any disadvantage to the behavior of IE, Opera and the like?
>>>
>>> Well, obviously, it makes it impossible to send a backslash to the
>>> server in the case where it really wants one.
>>
>> That's the only disadvantage I could come up with, but I haven't seen a
>> file or directory name with a backslash in it so far. AFAIK, in the
>> position the backslash was in the URL in question it wouldn't have been
>> a legal backslash, at least not for So I'm not sure whether this is
>> really a disadvantage.
>
> You're making the assumption that the components of a URL always represent
> directory and file names.
No, I'm not making that assumption. It is also irrelevant for my question.
> Sure, 99% of the time they do, because most web servers simply map a URL
> "path" directly onto a filesystem "path". However, it's actually up to
> each web server to define exectly what anything following the slash
> after the hostname actually means.
Correct, but doesn't answer the question.
> You're also assuming that anything that the webserver host OS accepts as
> a filesystem path separator should also be legal as a URL path
> separator.
No, I'm not assuming this. It is also irrelevant for my question.
> In HTTP, '\' is a "token separator" but not a path separator, except when
> used within a quoted string, in which case it is a one-character esacape.
> '/' is both a token separator and a path separator (but not inside a quoted
> string).
No contest, but not really relevant to my question.
The questions are:
What harm does it do to the normal web user (not a web developer) if a
browser attempts to fetch a URL that has an encoded backslash (%5C) in it
and isn't found by the server as it is a second time, this time with the
encoded backslash replaced by a forward slash?
And, when answered this one, the next one is: Do we know that the browsers
who guessed the correct URL don't send out the first request with the %5C
in it and only send out a request with the %5C replaced by a slash, and if
so, what (specific, not philosophic) harm does this do?
Is this so difficult to answer specifically? It may be, possibly because
there may be no real harm.
{Quote hidden}>>> Actually, if they're doing it right, they're making two requests -- one
>>> with the backslashes as originally specified, and then only when that
>>> fails, flipping them to forward slashes and trying again.
>>
>> If they do that, is there a disadvantage left? (For the user, not for a
>> web developer -- a web developer can use whatever tool is adequate for
>> checking correctness.)
>
> Sure! Even if the feature is implemented this way, there needs to be a way
> to turn it off.
Why? The only consequence of not being able to turn it off I see is that it
may make that browser less useful as a web developer tool. Which is largely
irrelevant for a normal user.
{Quote hidden}>> FWIW, what Firefox does is at least a bit odd. Take a normal, working URL
>> and replace a slash with %2F, for example
>>
http://server/dir1/dir2%2Fdocument.ext. Chances are that you get an error
>> page back stating that "document /dir1/dir2/document.ext can't be found on
>> this server" -- knowing that document /dir1/dir2/document.ext does exist.
>> While formally correct, it's still odd for the unsuspecting user and not
>> really user-friendly.
>
> Firefox's behavior is NOT odd. '\' is not a legal character in a URI (see
> RFC2396), so a browser HAS to URL-encode it using the "% hex hex" syntax.
>
> On the other hand, '/' is a "reserved" character in a URI, so it is a path
> separator if it is not URL-encoded, but treated as an ordinary character
> within a path element if it is encoded as %2F.
No contest to any of this, but you seemed to have missed my point.
On a closer look, it's actually the server that does strange things, not
Firefox. Check out
<http://www.incois.gov.in/Tutor/science+society%2Flecture2.html> for
example. The error message it at least odd... if not downright wrong. But,
as I said, it's not Firefox.
> All of this is carefully spelled out in the RFCs. Any browser that plays
> fast and loose with this stuff is headed into dangerous territory.
So far, no evidence has been presented that any of the browsers that
displays the page as intended "plays fast and loose" (whatever this means)
or violates any RFC.
Take for example the relationship between what's in the address field and
what the result of this is... Try to type "analog" (nothing more) in
Firefox's address field. It won't just try to fetch the "URL" <analog> and
return with an error. It tries to guess a few things and finally comes up
with <http://www.analog.com/>. This behavior is widely accepted and even
expected, but it's not spelled out in any RFC -- is it "fast and loose"?
User interface behavior is not part of the RFCs; they don't specify to what
degree a user agent may or may not filter or otherwise change user requests
before placing them on the wire, and specifically there's nowhere written
that a browser is not allowed to try to guess a URL that doesn't resolve
and see whether it can come up with one that does and has a good chance to
be the one that was intended. I'm pretty sure that the http requests that
IE, Opera et al sent out when fetching this page were RFC conformant, just
like the requests that Firefox sends out. What happens between the requests
on my computer is (gladly) not (yet?) determined by RFCs -- they determine
what happens (or should happen) "on the wire".
Gerhard
2008\05\27@115630
by
Alan B. Pearce
>> Very clever. I would alter it to display in 24 hour
>> fashion.
>>
>>> http://www.romanblack.com/binclk.htm
>
>24 hour add on is easy enough. Maybe a thin line full width
>line somewhere.
I thought the answer was already on the page - change colour for the other
12 hours ...
2008\05\27@123902
by
Michael Rigby-Jones
|
> -----Original Message-----
> From: @spam@piclist-bouncesKILLspammit.edu [KILLspampiclist-bouncesKILLspammit.edu] On
Behalf
> Of Gerhard Fiedler
> Sent: 27 May 2008 16:21
> To: RemoveMEpiclistTakeThisOuTmit.edu
> Subject: Re: [EE] Roman Black is allive and is designing clocks...
>
>
> The questions are:
>
> What harm does it do to the normal web user (not a web developer) if a
> browser attempts to fetch a URL that has an encoded backslash (%5C) in
it
> and isn't found by the server as it is a second time, this time with
the
> encoded backslash replaced by a forward slash?
>
> And, when answered this one, the next one is: Do we know that the
browsers
> who guessed the correct URL don't send out the first request with the
%5C
> in it and only send out a request with the %5C replaced by a slash,
and if
> so, what (specific, not philosophic) harm does this do?
>
> Is this so difficult to answer specifically? It may be, possibly
because
> there may be no real harm.
Ignoring any potential security issues, if browsers are programmed to
try and guess what a "broken" web site should look like, then surely
there is less incentive for web developers to fix them properly? This
would then behove other browsers to follow suite, and soon the RFC's are
a long forgotten memory.
Essentially this could be creating another standard, something that MS
has been slated for many times. How is this different?
Regards
Mike
=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
2008\05\27@165009
by
Gerhard Fiedler
|
|
Michael Rigby-Jones wrote:
>> The questions are:
>>
>> What harm does it do to the normal web user (not a web developer) if a
>> browser attempts to fetch a URL that has an encoded backslash (%5C) in
>> it and isn't found by the server as it is a second time, this time with
>> the encoded backslash replaced by a forward slash?
>>
>> And, when answered this one, the next one is: Do we know that the
>> browsers who guessed the correct URL don't send out the first request
>> with the %5C in it and only send out a request with the %5C replaced by
>> a slash, and if so, what (specific, not philosophic) harm does this do?
>>
>> Is this so difficult to answer specifically? It may be, possibly
>> because there may be no real harm.
>
> Ignoring any potential security issues, if browsers are programmed to
> try and guess what a "broken" web site should look like, then surely
> there is less incentive for web developers to fix them properly?
Maybe. With that seem to be saying that web developers are more dangerous
than broken browsers... because the problem, according to how I read this,
is not that a browser can catch an occasional error and avoid that a user
is bothered with it, but rather that web developers don't do their job.
Given this, I think the solution are not browsers that show these errors to
users... that's just another crutch. The real solution to the stated
problem is to somehow change the attitude of web developers. I don't feel
that me looking at broken web pages like the one in question somehow
achieves this.
> Essentially this could be creating another standard, something that MS
> has been slated for many times.
Regarding web standards, I'm not sure there is strong evidence that
Microsoft created more standards than, say, Netscape. IIRC, there were
/lots/ of non-standard features in Netscape's browser.
Gerhard
2008\05\27@165052
by
Dave Tweed
|
|
Gerhard Fiedler wrote:
> If the above was only "partly" a joke, you better should have taken it
> seriously when you wrote it.
I did. Engineering is all about doing it right in the first place, not
compensating for errors in one place by implementing nonstandard behavior
in another.
This conversation is becoming pointless. You just want "whatever it takes"
to get the job done, even in the face of gross errors and sloppy testing,
while the rest of us are interested in adhering to standards so that
different components of an overall system such as the WWW can work
interchangeably. We're just going to have to agree to disagree.
> User interface behavior is not part of the RFCs; they don't specify to
> what degree a user agent may or may not filter or otherwise change user
> requests before placing them on the wire, ...
But we're not talking about "user requests", we're talking about resource
links that the website designer has embedded in a page. If he can't count
on getting those requests back exactly as he intended them, what can he
count on? There are indeed very specific rules about how a browser is
supposed to combine a relative URL with a base URL in order to generate a
complete HTTP request.
-- Dave Tweed
2008\05\27@165531
by
Gerhard Fiedler
Michael Rigby-Jones wrote:
> Ignoring any potential security issues,
What are the potential security issues with this behavior?
Gerhard
2008\05\27@183144
by
sergio masci
On Tue, 27 May 2008, Gerhard Fiedler wrote:
> Michael Rigby-Jones wrote:
>
> > Ignoring any potential security issues,
>
> What are the potential security issues with this behavior?
>
This is left as an exercise for the reader.
Regards
Sergio Masci
2008\05\27@222443
by
Gerhard Fiedler
sergio masci wrote:
> On Tue, 27 May 2008, Gerhard Fiedler wrote:
>> Michael Rigby-Jones wrote:
>>
>>> Ignoring any potential security issues,
>>
>> What are the potential security issues with this behavior?
>
> This is left as an exercise for the reader.
Obviously, since so far nobody could cite one, it seems too difficult for
the writer :)
Seriously, if sending URLs with forward slashes in the URL path to your web
server is a security risk, you definitely should look into your server
and/or web application.
Gerhard
2008\05\27@223849
by
Gerhard Fiedler
|
|
Dave Tweed wrote:
> I did. Engineering is all about doing it right in the first place, not
> compensating for errors in one place by implementing nonstandard behavior
> in another.
You assume that you _can_ do it right. I can't fix Roman's page. Between
manually copying the image URLs one by one, fixing them manually and
loading them one by one outside the context of the page on one hand and
having the browser do this rather obvious job on the other hand, I prefer
the browser doing it. That's as close as I can get to "fixing it".
> This conversation is becoming pointless. You just want "whatever it takes"
> to get the job done, even in the face of gross errors and sloppy testing,
As long as you walk into this conversation with this obvious prejudice that
is not related to anything I wrote in this thread, it is of course
pointless. I thought you might actually be interested to talk about the
issue, rather than spread your completely unfounded opinion about me.
> while the rest of us are interested in adhering to standards so that
> different components of an overall system such as the WWW can work
> interchangeably.
Where did I ever write that I don't want adhere to standards? Have you ever
seen work I did? Have I ever promoted not to adhere to standards?
>> User interface behavior is not part of the RFCs; they don't specify to
>> what degree a user agent may or may not filter or otherwise change user
>> requests before placing them on the wire, ...
>
> But we're not talking about "user requests",
Of course I am. Requesting a page to be displayed _is_ a user request, and
all the details below that request are a consequence of this request.
Displaying a page with broken images doesn't do me any good when I can't
fix the image hrefs.
> we're talking about resource links that the website designer has embedded
> in a page. If he can't count on getting those requests back exactly as
> he intended them
I'm rather sure that Firefox does _not_ send the requests back in the way
Roman intended them to be sent back. IE and Opera do.
> what can he count on? There are indeed very specific rules about how a
> browser is supposed to combine a relative URL with a base URL in order
> to generate a complete HTTP request.
Yes, but there is nothing in any RFC whether the browser can't try other
combinations in the case that the "correct" interpretation doesn't work.
Rather than relying on browsers to check for "correctness", how about using
real tools for that, like
<http://validator.w3.org/checklink?uri=http%3A%2F%2Fwww.romanblack.com%2Fbinclk.htm&hide_type=all&depth=&check=Check>
or
<http://validator.w3.org/check?uri=http%3A%2F%2Fhttp://www.romanblack.com%2Fbinclk.htm&charset=%28detect+automatically%29&doctype=Inline&group=0>?
If web developers did that a bit more often, we wouldn't need browsers to
be the main tool to check for correctness -- and people wouldn't fall all
over themselves when someone suggests that a web browser that displays a
formally broken page nevertheless correctly is as close to the devil as a
programmer's tool can get.
Gerhard
2008\05\28@071120
by
sergio masci
|
|
On Tue, 27 May 2008, Gerhard Fiedler wrote:
{Quote hidden}> sergio masci wrote:
>
> > On Tue, 27 May 2008, Gerhard Fiedler wrote:
> >> Michael Rigby-Jones wrote:
> >>
> >>> Ignoring any potential security issues,
> >>
> >> What are the potential security issues with this behavior?
> >
> > This is left as an exercise for the reader.
>
> Obviously, since so far nobody could cite one, it seems too difficult for
> the writer :)
Yes I remember some similar remarkes when I looked into licensing a third
party compiler to use as part of my tool chain. I ended up writing the
XCSB compiler :)
>
> Seriously, if sending URLs with forward slashes in the URL path to your web
> server is a security risk, you definitely should look into your server
> and/or web application.
When I use other peoples apps or libraries I don't really want to waste my
time testing or debugging them. In some cases I couldn't even if I wanted
to (e.g. no time, no source etc).
And it's not just about sending '/' instead of '\', it's about servers AND
browsers AND CGIs AND libraries and browsers running scripts embedded in
the page AND...
I originally suggested you have a look with google but you dismissed that
as if I were trying get you to do something that I could not be bothered
to. The fact is I did start looking before I suggested it and came up with
too much stuff to look at quickly - hence you want proof you look for it.
I'm happy in my inital assessment.
Regard
Sergio Masci
http://www.xcprod.com
2008\05\28@082323
by
Gerhard Fiedler
|
|
sergio masci wrote:
>> Seriously, if sending URLs with forward slashes in the URL path to your web
>> server is a security risk, you definitely should look into your server
>> and/or web application.
>
> When I use other peoples apps or libraries I don't really want to waste my
> time testing or debugging them. In some cases I couldn't even if I wanted
> to (e.g. no time, no source etc).
When you use code from someone else, you either trust it or you test it or
you have someone you trust test it. There are not really any other options.
But what does this have to do with the issue at hand?
> And it's not just about sending '/' instead of '\', it's about servers AND
> browsers AND CGIs AND libraries and browsers running scripts embedded in
> the page AND...
No. It is specifically about a URL with embedded and encoded backslashes
that was sent back with the embedded and encoded backslash converted to a
forward slash. You called that a security risk. I asked you to provide one
scenario where this would be a security risk. So far you didn't provide
one. From my experience designing web applications, I'm quite positive that
this is not a security risk, but I'm also willing to let you convince me --
it just needs a reasonable scenario.
Of course, browsers and all you mention are security risks in a general
sense, but to what degree browsers are more or less "forgiving" with
non-standard or even wrong HTML has little to do with this. Hackers don't
have to rely on browsers (and probably rarely do) to create their attack
requests. Any security of a web server or web site that relies on any
specific browser behavior is seriously broken right from the start. You can
open an http connection to any web server using a simple telnet terminal
and send to the server what you want -- literally. And people do that.
Don't rely on browser behavior for security; it's irrelevant. Also RFCs are
not that relevant for security; you need to be able to handle safely
everything you possibly may receive, not just standard-conform requests.
It may really be worth your while to go back and look at this specific
issue. Go to Roman's page in question, look at the image hrefs and find out
what you have to do to them to make them load. Then put that into the
context of your (correct) allegation that backslashes in the path of URLs
can present a security risk. (I still think that if they do, that's a
serious bug with the web server, but we all know that bugs are possible.)
> I originally suggested you have a look with google but you dismissed that
> as if I were trying get you to do something that I could not be bothered
> to.
This is not true. I've done my homework. I just have already done that
since a long time ago, so that any search now wouldn't bring up that much
new, and not specifically about this issue. I don't think it would bring up
anything about a forward slash in a URL being a security risk, in a general
sense.
> The fact is I did start looking before I suggested it and came up with
> too much stuff to look at quickly - hence you want proof you look for it.
> I'm happy in my inital assessment.
Can you please post at least one link that suggests that this specific
scenario is a security risk for any of the common web servers? If there is
so much stuff, that should be easy. But it seems you just glanced over it,
saw that there are many ways to try to break a web application (but still
few to succeed in that with a good one) -- but this specific issue didn't
necessarily come up in any of them. (Most of the security risks are either
bugs in browsers or web applications "tricked" through arguments they don't
handle properly -- forgotten to properly quote etc. In both there is a
potential for backslashes to create trouble, BTW.)
I'm not saying there are no security risk, and of course when designing a
web application you have to look quite closely at many things -- and one of
them is that any possible URL that your web server may try to handle must
not be a security risk.
But your first comment was that sending backslashes to the server may be a
security risk. While this is true, you consistently seem to miss the point
that the standard-conform behavior in this case involves sending an encoded
backslash back to the server. So if this is a security risk, so be it --
Roman Black wrote that URL into his page, and the standard requires that it
be sent back to the server, right? There's not much a browser can do about
this; the server simply needs to be prepared to handle the request without
creating a security risk. But then, if the server can handle this
straight-forward standard-conform behavior, why should it have a problem
with the more "normal" guessed URL that IE, Opera and possibly others try?
This one does _not_ include a backslash, not encoded and not unencoded --
the encoded backslashes have been replaced by forward slashes.
Gerhard
2008\05\28@084550
by
Michael Rigby-Jones
|
|
> -----Original Message-----
> From: spamBeGonepiclist-bouncesspamBeGonemit.edu [TakeThisOuTpiclist-bouncesEraseMEspam_OUTmit.edu] On
Behalf
{Quote hidden}> Of Gerhard Fiedler
> Sent: 27 May 2008 21:51
> To:
RemoveMEpiclistTakeThisOuTmit.edu
> Subject: Re: [EE] Roman Black is allive and is designing clocks...
>
> Michael Rigby-Jones wrote:
>
> > Ignoring any potential security issues,
>
> What are the potential security issues with this behavior?
I'm not as browser security expect so I don't know that there are any.
Equally I don't know that there are not, hence 'potential'.
Given the large number of security holes that have been discovered in
fairly innocuous looking browser features it always wise to be
suspicious of apparently trivial changes.
Regards
Mike
=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
2008\05\28@093320
by
Apptech
I'd suggest that the subject line could do with changing.
Whether OT is a better venue is moot.
...
> Given the large number of security holes that have been
> discovered in
> fairly innocuous looking browser features it always wise
> to be
> suspicious of apparently trivial changes.
...
2008\05\28@153017
by
M. Adam Davis
On 5/25/08, Gerhard Fiedler <listsEraseME.....connectionbrazil.com> wrote:
> FWIW, IE decodes the image URLs correctly and displays the images.
FWIW IE does NOT follow the RFC for URL encoding, and that means that
when I make a webpage that has windows users copy path information
from their file system into a text box on a webpage and post that to
my website for various reasons then I have to work around this BUG
that IE continues to use to support web developers that don't follow
internet standards. I further can't use the standard javascript
encode routine to alter the URL - IE just decodes it, so I have to
write and debug a new routine that enables a custom encoding (which
further must fit within the correct URL encoding, meaning it's much
stricter) and then use the reverse on the other end.
What IE has done, essentially, is ELIMINATED the use of the \ for
anything other than a bad path delimiter - they've dropped a character
(for which there is a completely valid encoding - %5C - from the
character set.
How is that in any way acceptable?
It also means new developers get to work around this BUG and waste
time while using a perfectly good character:
http://silverlight.net/forums/t/16247.aspx
www.netmechanic.com/news/vol4/html_no18.htm
http://www.cs.tut.fi/~jkorpela/www/revsol.html
There are times when one wants to pass a path to the webserver as a
parameter for a script. For readability '\' is a perfect answer - '/'
isn't allowed except as a path, and no other character conveys to the
user what the parameter is about as well. Regardless of how the
developer wants to use it, it shouldn't be artificially restricted
because it's what windows systems use as a path delimiter - take your
MS specific standards out of my web standards, please.
What IE SHOULD be doing is converting any "\" to %5C before sending it
to the webserver, and not modifying any "%5C" found in the URL.
If the web developer insists on using non standard UNIFORM RESOURCE
LOCATOR techniques, then they should deal with the conversion on their
end, not force clients to adopt their personal style.
Trying the correct URL first, and only on error attempting another hit
would only increase the load on servers and make it take longer to get
the content - slowing down the site.
In other words, covering up a problem caused by someone not following
standards degrades the experience for everyone.
I hope this is still OK for EE - I use backslashes in my embedded HTTP
clients, and can't test the server applications from IE.
-Adam
--
EARTH DAY 2008
Tuesday April 22
Save Money * Save Oil * Save Lives * Save the Planet
http://www.driveslowly.org
More... (looser matching)
- Last day of these posts
- In 2008
, 2009 only
- Today
- New search...
![http://www.romanblack.com/.%5Cbinclock%5Cbinclk01.gif"](http://www.romanblack.com/.%5Cbinclock%5Cbinclk01.gif"){kind=link}
![http://www.romanblack.com/./binclock/binclk01.gif",](http://www.romanblack.com/./binclock/binclk01.gif",){kind=link}