NEW 46736
Script to modify http (and websocket) tests to work on ethernet interfaces other than 127.0.0.1/localhost 
https://bugs.webkit.org/show_bug.cgi?id=46736
Summary Script to modify http (and websocket) tests to work on ethernet interfaces ot...
David Kilzer (:ddkilzer)
Reported 2010-09-28 10:42:54 PDT
* SUMMARY There are times when it would be nice to be able to automatically modify http and websocket layout tests so that they would work on an external interface instead of just 127.0.0.1/localhost. Currently, this is a very manual process. This would make it easier to run the layout tests on mobile devices instead of requiring the test sources be copied over, running a web server and then invoking run-webkit-tests on the device.
Attachments
Add attachment proposed patch, testcase, etc.
David Kilzer (:ddkilzer)
Comment 1 2010-09-28 10:50:54 PDT
On possibility would be to create *.in copies of all the files that need to be changed, then replace "127.0.0.1" and "localhost" with unique tokens. Then when the script is run, it takes an IP address and a hostname as arguments, then copies the *.in files to their counterparts while replacing the unique tokens. This makes it possible to modify all of the tests in your local working directory at once, but also revert them easily for running layout tests via DumpRenderTree. (The *.in files should also be ignored by run-webkit-tests.)
Alexey Proskuryakov
Comment 2 2010-09-28 11:49:51 PDT
How many of the tests don't work, and what are the manual steps normally needed to make them work? I suspect it's mostly security tests, where we differentiate between 127.0.0.1 and localhost, is that correct?
Andrei Popescu
Comment 3 2010-09-30 02:38:32 PDT
Thanks for copying us on this bug. The way we got around this problem on Android was by using port forwarding on the device. 127.0.0.1:SomePortNumber can be configured to forward to any port on the host machine (attached to the device via USB). However, we do have a related problem where a few layout tests assume that they were loaded from a local file (one example is dom/html/level2/html/HTMLDocument03.js, where the domain is assumed to be the empty string). As we load all tests via HTTP, these tests fail.
David Kilzer (:ddkilzer)
Comment 4 2010-09-30 03:55:07 PDT
(In reply to comment #2) > How many of the tests don't work, and what are the manual steps > normally needed to make them work? I don't have a test count. I've never tried to run all of the http and websocket tests against another interface. When a test does fail, it's because it expects to be run from 127.0.0.1 and uses "localhost" as a non-matching security origin. > I suspect it's mostly security tests, where we differentiate between > 127.0.0.1 and localhost, is that correct? Correct.
David Kilzer (:ddkilzer)
Comment 5 2010-09-30 03:57:59 PDT
(In reply to comment #3) > Thanks for copying us on this bug. The way we got around this problem > on Android was by using port forwarding on the device. > 127.0.0.1:SomePortNumber can be configured to forward to any port on > the host machine (attached to the device via USB). Thanks! > However, we do have a related problem where a few layout tests assume > that they were loaded from a local file (one example is > dom/html/level2/html/HTMLDocument03.js, where the domain is assumed > to be the empty string). As we load all tests via HTTP, these tests fail. That sounds like a different issue. Have you filed a bug report about it yet?
Note You need to log in before you can comment on or make changes to this bug.