How to get the response text for the script tag?

  • Thread starter pramodrathod007
  • Start date
P

pramodrathod007

Hi All,

Is there any way to modify the response got from the script tag's
source URL (src="url")?
I want to restrict the response from loading into the document.

Below is the scenario
-------------------------------

I am using the script tag to send an asynchronous request to a servlet
of other domain.
(As AJAX can not be used to send a cross-domain request)

<script type="text/javascript" src="http://domain:port/app/servleturl?
parm1=val1" />

The above script tag is generated dynamically through javascript and
appended into the head tag.

In the response I am getting the html text
("<html><head><script>window.close();</script></head></html>") which
is causing a syntax error on IE.

Sample test code:
<html>
<head>
</head>
<body>
<!-- Asynchronous request-->
<script src="http://www.google.com"></script>
</body>
</html>

Here I am only bothered about sending the request and don't want do
anything with the response from the servlet.

Is there any way to catch the response text for the script tag as we
do with the XMLHttpRequest object?

Thanks.

Regards,
Pramod
 
D

David Mark

Hi All,

Is there any way to modify the response got from the script tag's
source URL (src="url")?
I want to restrict the response from loading into the document.

Below is the scenario
-------------------------------

I am using the script tag to send an asynchronous request to a servlet
of other domain.
(As AJAX can not be used to send a cross-domain request)

<script type="text/javascript" src="http://domain:port/app/servleturl?
parm1=val1" />

Never omit said:
The above script tag is generated dynamically through javascript and
appended into the head tag.

In the response I am getting the html text
("<html><head><script>window.close();</script></head></html>") which
is causing a syntax error on IE.

Or anything. Looks like there is a serious problem with the servlet.
Nothing you can do about that on the client.
 
S

SAM

Le 12/8/08 9:56 AM, (e-mail address removed) a écrit :
Hi All,

Is there any way to modify the response got from the script tag's
source URL (src="url")?
I want to restrict the response from loading into the document.

Below is the scenario
-------------------------------

I am using the script tag to send an asynchronous request to a servlet
of other domain.
(As AJAX can not be used to send a cross-domain request)

<script type="text/javascript" src="http://domain:port/app/servleturl?
parm1=val1" />

The above script tag is generated dynamically through javascript and
appended into the head tag.

In the response I am getting the html text
("<html><head><script>window.close();</script></head></html>") which
is causing a syntax error on IE.


window.close();

You can't close a window if it has not previously been opened by
JavaScript !

or the response would have to be :
str="<html><head><script>window.close();<\/script><\/head><\/html>";

incidentally :
with(document){open();write(str);close();};
 
T

Thomas 'PointedEars' Lahn

Is there any way to modify the response got from the script tag's
source URL (src="url")?
No.

I want to restrict the response from loading into the document.

Don't use a `script' element, then.
[...]
<script type="text/javascript" src="http://domain:port/app/servleturl?
parm1=val1" />

The above script tag is generated dynamically through javascript and
appended into the head tag.

In the response I am getting the html text
("<html><head><script>window.close();</script></head></html>") which
is causing a syntax error on IE.

It causes a syntax error *anywhere* as it is considered a client-side
script and `<' is considered an operator before an operand was parsed.
Sample test code:
<html>
<head>
</head>
<body>
<!-- Asynchronous request-->

Nonsense, that is as "synchronous" as it can get:
<script src="http://www.google.com"></script>

Won't work because HTML (that this URL yields) is _not a script_ and the
`type' attribute is required, but missing here.
</body>
</html>

Here I am only bothered about sending the request and don't want do
anything with the response from the servlet.

Look, a `script' element is for running *client-side* *script* code.
That's *HTML basics*.
Is there any way to catch the response text for the script tag as we
do with the XMLHttpRequest object?

No, and it's a `script' *element* to begin with.


PointedEars
 
B

Bunty

Hi Davis, SAM, & Thomas,

Thanks a ton!

Thomas:
Thanks again for your point to point review. A few more questions on
the same line..
- Why don't we get the syntax error on FF & Chrome or Safari?
- If I create the script tag dynamically through DOM and add it into
the document
- Will it be a synchronous or asynchronous request? Is there any way
to identify this?
- The required functionality and what I am trying to achieve is to
send an asynchronous request to a servlet which is deployed outside
the domain. No processing is needed on the response.... I am also not
expecting any javascript from the <script> tag... as it is being used
to invoke a servlet on another domain. It's analogues to the html
<form.. action="url"> submit functionality achieved through the
XMLHttpRequest API method's... Unfortunately AJAX does not allow you
to send a request to another domain.
And only the <script type=".." src=".."></script> is allowed to do
this......

Regards,
Pramod
 
T

Thomas 'PointedEars' Lahn

Bunty wrote:
^^^^^
You should decide for a name, preferably your real name.
Hi Davis, SAM, & Thomas,

Thanks a ton!

Thomas: Thanks again for your point to point review.

You are welcome.
A few more questions on the same line..

Please post properly next time, that is, only one `>' per quotation level
(and *no* prefix for new text).

<http://jibbering.com/faq/#posting>

[Quoting fixed]
Why don't we get the syntax error on FF & Chrome or Safari?

Well, "we" do because "we" know we have to look in the error console there.
Apparently *you* don't. Although you ought to have known better as it is
mentioned all over the place said:
If I create the script tag

Again, it is a `script' _element_. It consists of a start tag (`<script
....>'), content (which is optional here), and an end tag (`</script>').

dynamically through DOM and add it into the
document Will it be a synchronous or asynchronous request?

Impossible to say. I think it is safe to say that it will be asynchronous
in the sense that execution of the script that issued the download will
continue while the other script is downloading, because the user agent is
to handle the latter instead.

However, an HTTP/1.1 client SHOULD NOT maintain more than 2 persistent
connections (those are the default type) to the same server or proxy (see
RFC2616, section 8.1.4), so loading of the other script may as well be
suspended until another HTTP connection had been established.
Is there any way to identify this?

There are several that come to mind, but since there is no standard for this
it is not reliable in the first place, so it appears to be rather a waste of
time to even attempt it. (What is sufficiently reliable as a general
concept is including all scripts this way to implicitly include other
scripts when necessary. But since there is a more reliable alternative --
to include the `script' elements in working order in the first place -- one
would seldom use this approach.)
The required functionality and what I am trying to achieve is to send
an asynchronous request to a servlet which is deployed outside the
domain. No processing is needed on the response.... I am also not
expecting any javascript from the <script> tag... as it is being used to
invoke a servlet on another domain.

But you will have to accept that this approach is utter nonsense. The
`script' element MUST load or contain a (syntactically valid) client-side
script; this is its purpose. And loading anything else must result in a
syntax error (explicitly displayed or not), because the script engine is not
designed to handle it. For example, a common error are scripts that are
referenced wrong which causes the server to send an error document (HTML or
XHTML) which in turn causes a syntax error with the script engine.
[...] Unfortunately AJAX does not allow you to send a request
to another domain. And only the <script type=".." src=".."></script> is
allowed to do this......

You are mistaken. *Any* element that can initiate a HTTP request on display
can be used, and *any other* element should be used here. Among them are
the `img', `iframe', and `object' elements, whereas the former two are more
common. And I have to emphasize again that these are *HTML* basics, rather
off-topic here (HTML is on-topic in comp.infosystems.www.authoring.html
instead). Please RTFM.


PointedEars
 
B

Bunty

Hi Thomas,

Wow! Thanks a lot! Really great answers.
I do agree that my approach is a bitter way and surely I will try
other approaches as well.
('img', 'iframe' etc.)

Thanks again.

Regards,
Bunty
 
J

Jorge

Wow! Thanks a lot! Really great answers.
I do agree that my approach is a bitter way and surely I will try
other approaches as well.
('img', 'iframe' etc.)

In either case, the browser is going to keep waiting for a response:
IOW, the server should send in reply a resource of the requested type,
even though you're going to discard it at the client-side.

But an empty file is a syntactically correct script, and as valid for
your purposes as a 1px*1px <img> or any other <tag> request. So why
not just reply to the <script> request with an empty file ?
 
B

Bunty

In either case, the browser is going to keep waiting for a response:
IOW, the server should send in reply a resource of the requested type,
even though you're going to discard it at the client-side.

But an empty file is a syntactically correct script, and as valid for
your purposes as a 1px*1px <img> or any other <tag> request. So why
not just reply to the <script> request with an empty file ?

Hi Jorge,

We initially opted the similar approach the <script> request with no
response. But it involves changes to be made in the server side code
as
well. As it needs to respond to both type of client the one who
expects
the response and the one who does not...

So we used the <img> tag to send a request to a servlet of other
domain.
We are adding a <img> dynamically through javascript DOM methods so
the
end effect is similar to that of AJAX request(Browser does everthing
in
the background).

Thanks.

Regards,
Bunty

"Freedom is not worth having if it does not include the freedom to
make mistakes."
 
B

Bunty

In either case, the browser is going to keep waiting for a response:
IOW, the server should send in reply a resource of the requested type,
even though you're going to discard it at the client-side.

But an empty file is a syntactically correct script, and as valid for
your purposes as a 1px*1px <img> or any other <tag> request. So why
not just reply to the <script> request with an empty file ?

Hi Jorge,

We initially opted the similar approach the <script> request with no
response. But it involves changes to be made in the server side code
as
well. As it needs to respond to both type of client the one who
expects
the response and the one who does not...

So we used the <img> tag to send a request to a servlet of other
domain.
We are adding a <img> dynamically through javascript DOM methods so
the
end effect is similar to that of AJAX request(Browser does everthing
in
the background).

Thanks.

Regards,
Bunty

"Freedom is not worth having if it does not include the freedom to
make mistakes."
 
J

Jorge

Hi Jorge,

We initially opted the similar approach the <script> request with no
response.


Hi Bunty,

ISTM that a server should reply to a request, because no matter what
kind of resource is requested, the browser will always expect a
response. It's not the same thing to reply with an empty <script> than
not replying at all (no response).

In most browsers, a request for a <script> (that never arrives) blocks
(until it either arrives or times out) any further requests for other
<scripts>, but a request for an <img> (wether it ever arrives or not)
doesn't block other further requests. That's (that your server doesn't
respond) probably the reason why you are having problems with
dynamically added <script>s and not with dynamically added <img>s.

If the server sent a response, even an empty one, then you'd have no
problems with (dynamically added) <script>s.

You can test it here: <http://jorgechamorro.com/cljs/027/>

Hitting the "load a script that takes 10 seconds to arrive" button
blocks (until loaded) the loading of the "load a script that should
arrive inmediatly" script, but not the loading of the images of the
"load an image" buttons.

Thanks to Steve Souders for lending :) his 10s-delayed-script at
<http://stevesouders.com/hpws/js-blocking.php>

Note: WebKit based browsers don't seem to block.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,999
Messages
2,570,243
Members
46,836
Latest member
login dogas

Latest Threads

Top