tsp asked a relatively innocent question, which led to an interesting result.

        Why can't we get to   http://www.royalroadl.com

It gives http error 503, temporarily out of service. That makes you think their 
server is down, so you walk away and try later. But you always get this 
misleading error, always.

The page has some skeleton html and a couple dozen lines of javascript.
The skeleton is a form that says they are checking our browser,
and could I wait a few seconds.
I waited, plenty long enough, and then pushed submit, and got the same page 
with the same 503 error and the same form back again.
Time to read through the somewhat cryptic javascript.
The function basically attaches another function to document under the event 
DOMContentLoaded, and that's it.
It never dispatches that event, which means we're suppose to, and we don't.
I read about DOMContentLoaded on the internet.
Is it suppose to come before or after onload? Not clear.
Is it suppose to run like a function, as we do with onload, or through the 
dispatchEvent system? Not clear.
I did it the easiest way possible, called document.onDOMContentLoaded() at the 
end of runOnload() in html.c.

And what would this function do if it were run?
It does all sorts of weird computations in javascript, and updates a hidden 
input field with the answer, then it submits the form.
When I submitted the form manually it didn't cut any ice, because js had not 
put the correct answer in the hidden field.
I had to run js, and update the field, and submit the form.
This went to another page on the website wich verified the answer.
Apparently it was correct, because http 302 redirected me back to the home 
page, yes, the very same home page,
and this time it let me in.  Code 200.
How did the home page know I had passed the test?
I didn't see any cookies fly by.
Did it record my IP address as ok?
That's rather crude; a thousand computers on an intranet can be behind one ip 
address as the gateway.
I don't know how it works on the server side, which frustrates me a little.
I do know that one line of code made the difference between being locked out 
and getting in. (Latest push).

1. Whoever said more and more sites will need js just to browse, was correct.

2. Whoever said events were critical to the success of edbrowse and javascript, 
was correct.

This is going to be a js intensive website, almost as bad as nasa.
I got you in, but not clear how many functions will work inside.
I'm sure we'll discover more things that we are missing, or not implementing 

Karl Dahlke
Edbrowse-dev mailing list

Reply via email to