This is Interesting: Free Magazines for Graphics designers and webmasters
Home > Archive > Webmaster forum > August 2006 > javascript and HTTP headers
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
javascript and HTTP headers
|
|
|
| I have a little project of logging into a vDeck control panel with a
server script.
I'm having some trouble as it is identifying the server as not having
javascript turned on.
Is there something in the headers that could indicate javscript? I
don't see anything client side that would.
Jeff
| |
| Andy Dingley 2006-08-17, 6:47 pm |
| Jeff wrote:
> I have a little project of logging into a vDeck control panel
[caveat] I've no experience of vDeck
> with a server script.
You don't really "log into a control panel" with a "server script", as
we usually think of them. If you're logging in to what I think, then
your script might be _running_ on a server, but what it's doing has
more in common with pretending to _be_ a client.
> I'm having some trouble as it is identifying the server as not having
> javascript turned on.
That's probably because your server, and the Perl(?) web robot script
it's running, don't support JavaScript. You might find this to be a
problem, you might even find it to be an insurmountable problem.
> Is there something in the headers that could indicate javscript?
No. This has to be indicated on the client side - there's no header
that can do it. Usually the JavaScript-requiring server sends out a
static page with the text "This doesn't support JavaScript" and the
client-side JavaScript (if available) over-writes this message with one
that says "Oh yes it does" (or similar).
Try to find out how to work the control panel without JavaScript. This
is certainly possible, because everything has to come down to HTTP in
the end. Then find a way to write a script that emulates thse HTTP
transactions. Focus on the transactions and the actuall data being
exchanged, not the way the page looks in the browser.
| |
|
| Andy Dingley wrote:
> Jeff wrote:
>
>
>
>
> [caveat] I've no experience of vDeck
>
>
>
>
> You don't really "log into a control panel" with a "server script", as
> we usually think of them. If you're logging in to what I think, then
> your script might be _running_ on a server, but what it's doing has
> more in common with pretending to _be_ a client.
Yes, that's exactly correct.
In this case using the PERL module LWP which can be programmed to send
out whatever headers or content you want.
>
>
>
>
>
> That's probably because your server, and the Perl(?) web robot script
> it's running, don't support JavaScript. You might find this to be a
> problem, you might even find it to be an insurmountable problem.
>
>
>
>
>
> No. This has to be indicated on the client side - there's no header
> that can do it. Usually the JavaScript-requiring server sends out a
> static page with the text "This doesn't support JavaScript" and the
> client-side JavaScript (if available) over-writes this message with one
> that says "Oh yes it does" (or similar).
That's about what I thought. I have the agent set to 'Mozilla/5.0'. I
know vDeck does agent sniffing because it servers up mozilla and
explorer stylesheets.
>
> Try to find out how to work the control panel without JavaScript.
Hmm, with javscript off (on my browser), I see a javascript redirect I
hadn't seen before!
self.location.href....
I have another problem though and I'll start a new thread on that shortly.
Thanks,
Jeff
This
> is certainly possible, because everything has to come down to HTTP in
> the end. Then find a way to write a script that emulates thse HTTP
> transactions. Focus on the transactions and the actuall data being
> exchanged, not the way the page looks in the browser.
>
|
|
|
| | Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |
|