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

**sasuke** · Sep 26 '08, 02:35 AM

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

On Sep 26, 4:12 am, Jeff Bigham <jeffrey.big... @gmail.comwrote :

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** · Sep 26 '08, 07:35 PM

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

sasuke wrote:

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.microso ft.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
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

**Jorge** · Sep 26 '08, 10:35 PM

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

On Sep 26, 9:28 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

>
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.microso ft.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 ?

--
Jorge.

**Thomas 'PointedEars' Lahn** · Sep 27 '08, 01:45 AM

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

Jorge wrote:

Thomas 'PointedEars' Lahn wrote:

>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.microso ft.com/kb/208427>.

>
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
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8 300dec7@news.de mon.co.uk>

**Jorge** · Sep 27 '08, 03:25 AM

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

On Sep 27, 3:42 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

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.

--
Jorge.

**sasuke** · Sep 27 '08, 06:45 AM

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

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/w...arameters.html

>

/sasuke

**Thomas 'PointedEars' Lahn** · Sep 27 '08, 06:25 PM

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

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@PointedEa rs.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.

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

- 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>
<http://www.w3.org/TR/1999/REC-html401-19991224/types.html#h-6.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/w...arameters.html

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

PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

**Thomas 'PointedEars' Lahn** · Sep 27 '08, 07:05 PM

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

Thomas 'PointedEars' Lahn wrote:

[...] 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
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

**sasuke** · Sep 27 '08, 07:15 PM

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

On Sep 27, 11:21 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
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@PointedEa rs.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.

- 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>
<http://www.w3.org/TR/1999/REC-html401-19991224/types.html#h-6.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?

Thought so, just wanted to make sure. Thanks.

<http://classicasp.aspfaq.com/forms/w...-querystring/g....

>
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** · Sep 27 '08, 07:25 PM

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

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
>>implementatio n decides on one [...] it should send a 414 response
>>code when such a situation is encountered.

>Yes, see also <news:48DD8F93. 70707@PointedEa rs.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?

Thanks for the references and clarifications.

You are welcome, but please trim your quotes more.

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

**sasuke** · Sep 27 '08, 08:05 PM

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

On Sep 28, 12:21 am, Thomas 'PointedEars' Lahn <PointedE...@we b.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

**Eric B. Bednarz** · Sep 29 '08, 06:05 PM

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

Thomas 'PointedEars' Lahn <PointedEars@we b.dewrites:

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>

**Jorge** · Sep 29 '08, 08:45 PM

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

On Sep 27, 9:21 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.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
>implementati on decides on one [...] it should send a 414 response
>code when such a situation is encountered.
Yes, see also <news:48DD8F93. 70707@PointedEa rs.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

**sasuke** · Sep 30 '08, 03:05 AM

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

On Sep 30, 1:36 am, Jorge <jo...@jorgecha morro.comwrote:

On Sep 27, 9:21 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.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
>>implementatio n decides on one [...] it should send a 414 response
>>code when such a situation is encountered.
>Yes, see also <news:48DD8F93. 70707@PointedEa rs.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.

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

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

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment