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

[Jeff Bigham]

Hi,

I'm getting an "Access is denied" error in IE when I try to focus an
input box with node.focus()

My understanding is that should only happen when the domains are
different of the Javascript and the element that its trying to focus.
It might be cross-frame, but everything comes from the same domain.

The oddest part about this is that even though I get the "Access is
denied" error, the textbox actually does focus. Perhaps odder still,
it seems to not happen if I put an alert() immediately before the
focus(). Perhaps it has something to do with the page having lost
focus when focus() is called?

Very strange behavior and, as usual, IE is basically no help in
isolating what the problem is.

Thanks for any help.

-Jeff

 

[sasuke]

Hi,

I'm getting an "Access is denied" error in IE when I try to focus an
input box with node.focus()

My understanding is that should only happen when the domains are
different of the Javascript and the element that its trying to focus.
It might be cross-frame, but everything comes from the same domain.

The oddest part about this is that even though I get the "Access is
denied" error, the textbox actually does focus.  Perhaps odder still,
it seems to not happen if I put an alert() immediately before the
focus().  Perhaps it has something to do with the page having lost
focus when focus() is called?

Very strange behavior and, as usual, IE is basically no help in
isolating what the problem is.

Maybe this would help. < http://www.dannyg.com/ref/jsminifaq.html#q15

Thanks for any help.

-Jeff

HTH,
/sasuke

 

[Thomas 'PointedEars' Lahn]

Maybe this would help. < http://www.dannyg.com/ref/jsminifaq.html#q15

Only the upper part could help. It becomes the usual Goodman nonsense
starting with "Setting the document.domain properties of both pages may
solve the problem". First of all, it does not solve the problem since
recent UAs tend to disregard this property and would make it read-only if
standards compliance is to be achieved; it would only solve the problem, as
this property was intended to function, if the second-level domain of both
requests were the same. And IE only shows the error (unless you have
disabled showing script errors, then there is only an error icon in the
status bar), other UAs exhibit the same behavior but might issue messages to
their background error consoles instead.

The nonsense goes on with "One more source of this error in IE ...". The
HTTP GET *command* (defined in RFCs 1945 and 2616) does NOT have a built-in
limit (for the request URI), especially not around 512 characters. In fact,
URIs have no limit defined (in RFC3986) at all, but Internet Explorer has
implemented a (quite annoying) limit of 2083 characters per URI -- an
information that is readily available in the MSKB, along with its
workaround, had Goodman the general intention to back up any of his
ridiculous claims: <http://support.microsoft.com/kb/208427>.

Incidentally, you should take everything Goodman says or writes with regard
to Web development with at least a handful of salt. You might get the
picture when I tell you that his facts hit rate appears to be even lower
than Resig's.


HTH

PointedEars

 

[Jorge]

The nonsense goes on with "One more source of this error in IE ...".  The
HTTP GET *command* (defined in RFCs 1945 and 2616) does NOT have a built-in
limit (for the request URI), especially not around 512 characters.  In fact,
URIs have no limit defined (in RFC3986) at all, but Internet Explorer has
implemented a (quite annoying) limit of 2083 characters per URI -- an
information that is readily available in the MSKB, along with its
workaround, had Goodman the general intention to back up any of his
ridiculous claims: <http://support.microsoft.com/kb/208427>.

But that's not a workaround. URIs are limited to 2083 bytes in IE.
Full stop. That you can send whatever in the headers or in the payload
of a POST is another completely different and unrelated matter. Do you
work for M$ or what ?

 

[Thomas 'PointedEars' Lahn]

But that's not a workaround. URIs are limited to 2083 bytes in IE.

No, to 2083 *characters*. On a side note, HTTP/1.1 allows servers to
support a limited Request-URIs length, and they SHOULD respond with a
special status code in the case the request URI is too long.

Full stop. That you can send whatever in the headers or in the payload
of a POST is another completely different and unrelated matter.

It is a solution for the problem that was suggested *both* by Goodman and
the MSKB. However, the problem was not properly analyzed by Goodman which
needed correction. That correction, made by me, was backed up with a
reference to the MSKB.

Do you work for M$ or what ?

Get a life.


PointedEars

 

[Jorge]

No, to 2083 *characters*.  On a side note, HTTP/1.1 allows servers to
support a limited Request-URIs length, and they SHOULD respond with a
special status code in the case the request URI is too long.

Well. Of course there's not much point in accepting a 200GB url,
right ?
But 2083 *characters* doesn't look like a reasonable maximum.
Furthermore, I can inject into a page or simply run a (longer that
2083 *characters*) program as a bookmarklet in any other browser
except IE. Always IE.

 

[sasuke]

Some more information which I found:

- Though as such there is no limit on the URI length; if the server
implementation decides on one or if the HTTP client erroneously
converts a given POST request to a GET, it should send a 414 response
code when such a situation is encountered.
- SGML specifies that the URL length in <a href='url'> can't be more
than 1024 characters.
- I still wonder why both the articles say that the POST data is send
in header when it actually forms a part of the HTTP Request Body?

< http://classicasp.aspfaq.com/forms/what-is-the-limit-on-querystring/get/url-parameters.html
/sasuke

 

[Thomas 'PointedEars' Lahn]

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.

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.

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

Utter nonsense. First of all, SGML does not specify the `a' element and its
`href' attribute; HTML does. Second, the length of attribute values in
applications of SGML is not limited; HTML is an application of SGML. Third,
the `href' attribute of the `a' element is defined in HTML to be of type
URI, and since the definition of that type refers to RFC1738 (obsoleted by
RFC4248, RFC4266; updated by RFC1808, RFC2368, RFC2396, *RFC3986*) there is
no theoretical limit on the length of the attribute value.

<http://xml.coverpages.org/sgmlsyn/sgmlsyn.htm#C7.9.4>

- I still wonder why both the articles say that the POST data is send
in header when it actually forms a part of the HTTP Request Body?

Utter incompetence?

< http://classicasp.aspfaq.com/forms/what-is-the-limit-on-querystring/get/url-parameters.html

Just another URI that you can strike through on your list of reliable
development resources.


PointedEars

 

[Thomas 'PointedEars' Lahn]

[...] 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

^^^^^^
telling the _client_

that the URI is too long for this server. See RFC2616, section 10.4.15.

<http://www.rfc-editor.org/rfc/rfc2616.txt>

PointedEars

 

[sasuke]

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:[email protected]>.

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.

Utter nonsense.  First of all, SGML does not specify the `a' element and its
`href' attribute; HTML does.  Second, the length of attribute values in
applications of SGML is not limited; HTML is an application of SGML.  Third,
the `href' attribute of the `a' element is defined in HTML to be of type
URI, and since the definition of that type refers to RFC1738 (obsoleted by
RFC4248, RFC4266; updated by RFC1808, RFC2368, RFC2396, *RFC3986*) there is
no theoretical limit on the length of the attribute value.



Utter incompetence?

Thought so, just wanted to make sure. Thanks.

Just another URI that you can strike through on your list of reliable
development resources.

*sigh* This makes it two in the same thread. I guess finding reliable
sources of gaining knowledge is like finding a needle in a haystack.
Thanks for the references and clarifications.

/sasuke

 

[Thomas 'PointedEars' Lahn]

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:[email protected]>.

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?

Thanks for the references and clarifications.

You are welcome, but please trim your quotes more.


PointedEars

 

[sasuke]

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

 

[Eric B. Bednarz]

sasuke wrote:

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.

 

[Jorge]

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 <
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.

 

[sasuke]

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 <
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.

 

[Thomas 'PointedEars' Lahn]

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>

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?

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?

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

Care to back that up?


PointedEars

 

[Eric B. Bednarz]

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.

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.

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.

 

[sasuke]

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