"Access is denied" in IE on node.focus() - Javascript

On Sep 28, 12:21 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Hmmm, my bad.  However, I am not sure what this is supposed to mean.  Is the
> Specification maybe referring to an HTTP proxy that would serve both as
> client and server, and thus could "convert" an incoming POST request madeby
> another HTTP client to it into an outgoing GET request made to another HTTP
> server?

But why convert; surely sounds strange.

I guess the answer here lies with the section 5.1.1 of the HTTP 1.1
specification.
/
========================================================================
| The list of methods allowed by a resource can be specified in an
| Allow header field (section 14.7). The return code of the response
| always notifies the client whether a method is currently allowed on
a
| resource, since the set of allowed methods can change dynamically.
An
| origin server SHOULD return the status code 405 (Method Not
Allowed)
| if the method is known by the origin server but not allowed for
the
| requested resource, and 501 (Not Implemented) if the method is
| unrecognized or not implemented by the origin server. The methods
GET

^^^^^^^^^^^^^^^
| and HEAD MUST be supported by all general-purpose servers. All
other

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| methods are OPTIONAL; however, if the above methods are
implemented,
^^^^^^^^^^^^^^^^^^^^^
| they MUST be implemented with the same semantics as those
specified
| in section 9.
==========================================================================

It might so happen that a proxy server knows that a HTTP Request made
by the client is of a type which is not supported by the target server
and hence attempts to convert the given POST request t o something
which is supported by all implementation viz. GET.

/sasuke

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> sasuke wrote:

>> - SGML specifies that the URL length in <a href='url'> can't be more
>> than 1024 characters.

To be a bit more precise, the SGML declaration of HTML 2 (RFC 1866) did
that. I totally fail to see, however, how SGML isues would be of any
relevance for a practical problem, since user agents never cared about
it (ok, Emacs W3 tried).

> Second, the length of attribute values in
> applications of SGML is not limited;

RTFM

> HTML is an application of SGML.

Oh yes, just not a conforming one.
Or an implemented one.
How exciting.

--
<http://tools.ietf.org/html/rfc1866#page-64>

On Sep 27, 9:21 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> sasuke wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> sasuke wrote:
> >>> Some more information which I found:
> >>>  - Though as such there is no limit on the URI length; if the server
> >>> implementation decides on one [...] it should send a 414 response
> >>> code when such a situation is encountered.
> >> Yes, see also <news:48DD8F93.70707@PointedEars.de>.
>
> >>> or if the HTTP client erroneously converts a given POST request to a GET, [...]
> >> Nonsense.  The HTTP client decides which type of request it makes.  The HTTP
> >> server MUST NOT process a GET request like a POST request and vice-versa.
> >> The server status code 414 is solely for the purpose of telling the server
> >> that the URI is too long for this server.  See RFC2616, section 10.4..15.
>
> > Yes, I read that, but the section says exactly the same thing as I
> > said about converting POST to GET requests.
>
> > /
> > ========================================================================
> > 10.4.15 414 Request-URI Too Long
> > |------------------------------------------------------------------------
> > |   The server is refusing to service the request because the Request-
> > |   URI is longer than the server is willing to interpret. This rare
> >                                                           ^^^^^^^^^
> > |   condition is only likely to occur when a client has improperly
> >     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > |   converted a POST request to a GET request with long query
> > |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > |   information, when the client has descended into a URI "black hole"
> > |   of redirection (e.g., a redirected URI prefix that points to a suffix
> > |   of itself), or when the server is under attack by a client attempting
> > |   to exploit security holes present in some servers using fixed-length
> > |   buffers for reading or manipulating the Request-URI.
>
> Hmmm, my bad.  However, I am not sure what this is supposed to mean.  Is the
> Specification maybe referring to an HTTP proxy that would serve both as
> client and server, and thus could "convert" an incoming POST request madeby
> another HTTP client to it into an outgoing GET request made to another HTTP
> server?
>

I think that that means that a form was submitted with method= 'get'
when it should have been submitted with method= 'post', because the
form's data is too long to fit in a decently-sized URI.

--
Jorge

On Sep 30, 1:36 am, Jorge <jo...@jorgechamorro.com> wrote:
> On Sep 27, 9:21 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>
>
>
> > sasuke wrote:
> > > Thomas 'PointedEars' Lahn wrote:
> > >> sasuke wrote:
> > >>> Some more information which I found:
> > >>>  - Though as such there is no limit on the URI length; if the server
> > >>> implementation decides on one [...] it should send a 414 response
> > >>> code when such a situation is encountered.
> > >> Yes, see also <news:48DD8F93.70707@PointedEars.de>.
>
> > >>> or if the HTTP client erroneously converts a given POST request to a GET, [...]
> > >> Nonsense.  The HTTP client decides which type of request it makes. The HTTP
> > >> server MUST NOT process a GET request like a POST request and vice-versa.
> > >> The server status code 414 is solely for the purpose of telling the server
> > >> that the URI is too long for this server.  See RFC2616, section 10..4.15.
>
> > > Yes, I read that, but the section says exactly the same thing as I
> > > said about converting POST to GET requests.
>
> > > /
> > > ========================================================================
> > > 10.4.15 414 Request-URI Too Long
> > > |------------------------------------------------------------------------
> > > |   The server is refusing to service the request because the Request-
> > > |   URI is longer than the server is willing to interpret. This rare
> > >                                                            ^^^^^^^^^
> > > |   condition is only likely to occur when a client has improperly
> > >     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > |   converted a POST request to a GET request with long query
> > > |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > |   information, when the client has descended into a URI "black hole"
> > > |   of redirection (e.g., a redirected URI prefix that points to a suffix
> > > |   of itself), or when the server is under attack by a client attempting
> > > |   to exploit security holes present in some servers using fixed-length
> > > |   buffers for reading or manipulating the Request-URI.
>
> > Hmmm, my bad.  However, I am not sure what this is supposed to mean.  Is the
> > Specification maybe referring to an HTTP proxy that would serve both as
> > client and server, and thus could "convert" an incoming POST request made by
> > another HTTP client to it into an outgoing GET request made to another HTTP
> > server?
>
> I think that that means that a form was submitted with method= 'get'
> when it should have been submitted with method= 'post', because the
> form's data is too long to fit in a decently-sized URI.

Oh yes, that sounds pretty logical; nice one. So I guess there are 3
reasons for the server returning a 414 [actually 3 causes for the same
reason; URI length too long]:

[-] improper conversion of POST to GET
[-] caused when a form is submitted with GET instead of POST.
[?] the proxy converting POST to GET since the target server doesn't
support POST (something which I mentioned in my previous post)

[?] URI "black hole" [what does this mean?]
[?]

[-] A cracker attempting to exploit security holes
[-] sending meaningless and exceptionally long URI's

/sasuke

P.S.: Is there even a newsgroup for discussing the HTTP specification?
All I could find were mailing lists related to HTTP issues / feature
request list.

Eric B. Bednarz wrote:
> Thomas 'PointedEars' Lahn <PointedE...@web.de> writes:
> > sasuke wrote:
> >>  - SGML specifies that the URL length in <a href='url'> can't be more
> >> than 1024 characters.
>
> To be a bit more precise, the SGML declaration of HTML 2 (RFC 1866) did
> that.

I see. HTML 2.0 is obsolete since June 2000 (RFC 2854); however
interesting that both HTML 3.2 and HTML 4.01 do impose a 64k
characters limit on the length of an attribute value after entity and
character references within it are interpreted (LITLEN):

<http://www.w3.org/TR/REC-html32#sgmldecl>
<http://www.w3.org/TR/1999/REC-html401-19991224/sgml/sgmldecl.html>

> I totally fail to see, however, how SGML isues would be of any
> relevance for a practical problem, since user agents never cared about
> it (ok, Emacs W3 tried).

What about W3C Amaya?

> >  Second, the length of attribute values in
> > applications of SGML is not limited;
>
> RTFM

OK, so there are applications of SGML that limit the length of
attribute values. However, there is no limit defined in SGML per se,
is there?

> > HTML is an application of SGML.
>
> Oh yes, just not a conforming one.
> Or an implemented one.

Care to back that up?


PointedEars

"Thomas 'PointedEars' Lahn" <PointedEars@web.de> writes:

> Eric B. Bednarz wrote:
>> Thomas 'PointedEars' Lahn <PointedE...@web.de> writes:
>> > sasuke wrote:
>> >>  - SGML specifies that the URL length in <a href='url'> can't be more
>> >> than 1024 characters.
>>
>> To be a bit more precise, the SGML declaration of HTML 2 (RFC 1866) did
>> that.
>
> I see. HTML 2.0 is obsolete since June 2000 (RFC 2854);

I kind of hoped that it was self-evident that this statement is
too dated even if it ever had any technical relevance. ;-)

> however
> interesting that both HTML 3.2 and HTML 4.01 do impose a 64k
> characters limit on the length of an attribute value after entity and
> character references within it are interpreted (LITLEN):

The longest posible attribute value literal is shorter of course, since
the maximum attribute specification length is equal to the maximum
literal length.

>> I totally fail to see, however, how SGML isues would be of any
>> relevance for a practical problem, since user agents never cared about
>> it (ok, Emacs W3 tried).
>
> What about W3C Amaya?

Fair question, I should have said mainstream user agents (before Mosaic
there was a browser with support for inline graphics, scripting and
stylesheets; no web developer I know in real life knows that .

Here we go…

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<title/foo/
<ul>
<li>asd
<>bar</>
</>

No, we don't have a winner here.

> OK, so there are applications of SGML that limit the length of
> attribute values. However, there is no limit defined in SGML per se,
> is there?

In absence of an explicit SGML declaration, there is the reference
concrete syntax, that limits attribute specification lengths to 960 and
literal lengths to 240 characters.

>> > HTML is an application of SGML.
>>
>> Oh yes, just not a conforming one.
>> Or an implemented one.
>
> Care to back that up?

In particular, section 7.2 smells very funny.
<http://www.w3.org/TR/html401/struct/global.html>

“The document type declaration names the document type definition (DTD)
in use for the document (see [ISO8879]).�

That’s the product of wild imagination, day dreaming or drugs, and
consequently there’s nothing to see in ISO 8879 in this respect.

It goes on saying “authors must include one of the following document
type declarations in their documents� which is supposed to mean
“restrict the document type declaration to this *notation*�. Obviously,
this is an extension of the aforementioned misbelief that document type
declarations have a ‘meta’ reference mechanism of sorts (like, say,
HyTime architectures).

As to the first error, I can’t quote something from a document that is
not present in it, as to the second, ISO 8879 clause 15.2.2 “Conformance
of Documents� says:

“A conforming SGML application […] shall not prohibit any markup that
this International Standard would allow in such documents.�

And that’s exactly what section 7.2 is trying to do (and doctype
sniffing is fundamentally based on).


As mentioned before in this group, the prose and the normative syntax
conflict for the ID attribute. If HTML was parsed according to its SGML
rules, the attribute value literal and the attribute value would be
different if the literal was not uppercase. Needless to say, that is not
exactly “case sensitive�, and would break at least page anchors and
getElementById.


The SGML Web TC (Annex K) is from 1997; had anybody cared about all this
arcane SGML stuff, one would think they would have found the time to
throw the dusty quantity and capacity stuff over board, unbundle the
shorttag feature, and do some other housekeeping for at least HTML 4.01.


I have the feeling we’ve been here before.

--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011

On Oct 2, 5:07 pm, Eric B. Bednarz <bedn...@fahr-zur-hoelle.org>
wrote:
> Fair question, I should have said mainstream user agents (before Mosaic
> there was a browser with support for inline graphics, scripting and
> stylesheets; no web developer I know in real life knows that .
>
> Here we go…
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
> <title/foo/
> <ul>
> <li>asd
> <>bar</>
> </>
>
> No, we don't have a winner here.

Truly amazing; it passes the W3C validator with flying colors!

/sasuke

sasuke wrote:
> Eric B. Bednarz wrote:
>> Fair question, I should have said mainstream user agents (before Mosaic
>> there was a browser with support for inline graphics, scripting and
>> stylesheets; no web developer I know in real life knows that .
>>
>> Here we go…
>>
>> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">

Missing system identifier forces a catalog lookup, see below.

>> <title/foo/

Equivalent to

<title>foo</title>

Cf. `<meta ... />' being invalid in HTML.

(The start tag of the `html' element, and the start and end tags of the
`head' element may be *O*mitted.)

>> <ul>

(The start tag of the `body' element may be *O*mitted.)

>> <li>asd

(The end tag of the `li' element may be *O*mitted.)

>> <>bar</>

Equivalent to

<li>bar</li>

>> </>

Equivalent to

</ul>

The end tag of the `body' and `html` elements may be *O*mitted.

>> No, we don't have a winner here.
>
> Truly amazing; it passes the W3C validator with flying colors!

There is nothing amazing about that; the W3C Validator obviously validates
against the SGML declaration and the DTD of the selected/detected markup
language according to its catalog of public identifiers. Which makes me
wonder what it would say about too long an attribute value.


X-Post & F'up2 ciwah, this is off-topic here.

PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann