tclwebtest-general Mailing List for tclwebtest (Page 3)
Status: Abandoned
Brought to you by:
tils
This list is closed, nobody may subscribe to it.
2003 |
Jan
(31) |
Feb
(61) |
Mar
(34) |
Apr
(2) |
May
(3) |
Jun
(2) |
Jul
(11) |
Aug
(17) |
Sep
(8) |
Oct
(7) |
Nov
|
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2005 |
Jan
(2) |
Feb
(6) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
(1) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Grzegorz A. H. <gr...@ef...> - 2003-08-29 07:25:07
|
On 2003-08-22, Tilmann Singer <ti...@ti...> wrote: > Unfortunately the selftests can't cover these things since they > require interaction with a server, but if the fix above works > for you feel free to commit it. Commited then. -- Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89. eFaber SL, Maria Diaz de Haro, 68, 2 http://www.efaber.net/ 48920 Portugalete, Bizkaia (SPAIN) |
From: Grzegorz A. H. <gr...@ef...> - 2003-08-26 07:48:49
|
On 2003-08-25, Grzegorz Adam Hankiewicz <gr...@ef...> wrote: > On 2003-08-22, Tilmann Singer <ti...@ti...> wrote: > > [...] You mind trying this new syntax? > [...] > > invalid command name "one_req" > > while executing > > "one_req" > > ("eval" body line 1) > > invoked from within > > "eval do_request $nocomplain_option $followequiv_option $location" > > (procedure "do_request" line 134) > > invoked from within > > [...] Simple shell tests fail too: $ tclsh % set ugh "Don't; like this" Don't; like this % eval puts $ugh Don't invalid command name "like" % set cmd [list puts $ugh] puts {Don't; like this} % eval $cmd Don't; like this % eval puts {$ugh} Don't; like this I think that the solution with braces would be ok if there were no empty parameters. In order to check which are empty or not, the proposed solution of building a list seems equally easy. I'm short of other suggestions. -- Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89. eFaber SL, Maria Diaz de Haro, 68, 2 http://www.efaber.net/ 48920 Portugalete, Bizkaia (SPAIN) |
From: Grzegorz A. H. <gr...@ef...> - 2003-08-26 07:11:17
|
On 2003-08-22, Tilmann Singer <ti...@ti...> wrote: > [...] You mind trying this new syntax? No luck: > [...] > --- do_request for http://192.168.1.50:8014/a-gastos/request-ae-2 > http status: >>302<< > following a redirect to: request-planning-travel?id=365&from=sel_new;one_req > --- do_request for http://192.168.1.50:8014/a-gastos/request-planning-travel?id=365&from=sel_new > http status: >>200<< > > invalid command name "one_req" > while executing > "one_req" > ("eval" body line 1) > invoked from within > "eval do_request $nocomplain_option $followequiv_option $location" > (procedure "do_request" line 134) > invoked from within > [...] -- Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89. eFaber SL, Maria Diaz de Haro, 68, 2 http://www.efaber.net/ 48920 Portugalete, Bizkaia (SPAIN) |
From: Grzegorz A. H. <gr...@ef...> - 2003-08-25 13:57:50
|
On 2003-08-22, Tilmann Singer <ti...@ti...> wrote: > * Grzegorz Adam Hankiewicz <gr...@ef...> [20030305 18:15]: > > Til, maybe it would be good to make a new release of > > tclwebtest. On the meantime, I was thinking about implementing > > a new command named validate. This command could be run over > > pages which are visible from the net and would call w3's validate > > engine over the page. Some examples: [...] > > [..] Anyway, for me the -tidy switch is sufficient, I guess you > found it by now? The tidy switch conflicts with the logging of the messages when run from inside our web interface. I get something like: stdout> --- TIDY START --- > warning: there is some error in tclwebtests code, can't determine return value of tidy > --- TIDY FINISH. RETURNS: (nix). URL: http://192.168.1.50:8014/a-gastos/request-show-travel?id=366&from= --- Which returns a false positive. It's low on my todo list to see where's the culprit and how can it be fixed. Besides, it runs automatically on everything, which sometimes is good, sometimes unwanted. -- Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89. eFaber SL, Maria Diaz de Haro, 68, 2 http://www.efaber.net/ 48920 Portugalete, Bizkaia (SPAIN) |
From: Tilmann S. <ti...@ti...> - 2003-08-23 10:01:31
|
* Molek, Gordon <GM...@ze...> [20030730 15:01]: > I was trying to develop a link-walk algorithm to validate that all the links > on a web-site > were valid and recursion combined with a list of already visited links > appeared to be the > way to implement it. In case you finished that - would you mind posting it? That would be an awesome addition to the tests distributed with tclwebtest. cheers, til -- http://tsinger.com |
From: Tilmann S. <ti...@ti...> - 2003-08-23 03:04:10
|
* Grzegorz Adam Hankiewicz <gr...@ef...> [20030730 10:18]: > When using [field select -index whatever], it would be nice if this > returned the selected text. The purpose of this would be selecting > something from the select at random, saving the text in a variable, > and check that the selected text appears somewhere in the next web > page after the form has been submited. Sounds useful. It seems a little bit complicated to insert a return value especially for one variant of the field command, maybe doing something like this in the test would be sufficient: field select -index whatever set selected_text [field get_selected_text] However, the selected_text attribute is not yet implemented - I'll try to remember it and see if I can add it one day (or somebody else is faster ;-) cheers, til -- http://tsinger.com |
From: Tilmann S. <ti...@ti...> - 2003-08-22 23:57:55
|
* Grzegorz Adam Hankiewicz <gr...@ef...> [20030818 11:54]: > Maybe tclwebtest could be modified to run inside a custom namespace > and then run the script with an `upvar' instead. Til, what do > you think? > > Anyway, the solution to your problem is easy, before `set myglobalvar > 79' put another `global myglobalvar' and it will work as expected: I'm not sure if tclwebtest should be changed to run tests in another level - I can't remember what the rationale behind the current design was (if there was any at all), but I'm afraid that a change would subtly change behaviour in other places, and if the only problem currently can be solved by calling 'global' inside the test again then it should be ok I guess. I'll try to add that to the docs. cheers, til -- http://tsinger.com |
From: Tilmann S. <ti...@ti...> - 2003-08-22 21:30:15
|
* Grzegorz Adam Hankiewicz <gr...@ef...> [20030305 18:15]: > Til, maybe it would be good to make a new release of tclwebtest. On > the meantime, I was thinking about implementing a new command > named validate. This command could be run over pages which are > visible from the net and would call w3's validate engine over the > page. Some examples: > > set url http://somedomain/some_page > validate $url [...] *wiping off dust from this message* ... this msg is from march, no idea why it spent so much time unanswered or if it got resolved/obsoleted by now. Anyway, for me the -tidy switch is sufficient, I guess you found it by now? tils@tp:~/tclwebtest$ ./tclwebtest Usage: tclwebtest [OPTIONS] [FILE|DIRECTORY]... [...] -tidy Toggle html check with tidy. Default off cheers, til -- http://tsinger.com |
From: Tilmann S. <ti...@ti...> - 2003-08-22 18:15:19
|
* Grzegorz Adam Hankiewicz <gr...@ef...> [20030822 18:19]: > Maybe there's something more to do? I've read again the chapter > about eval in my tcl manual and it says the difference between using > a list and curly braces is that the latter doesn't make variable > substitution immediate, which could be dangerous if the eval is > going to be used in another scope. > > But I don't understand what this has to do with the "Too many > positional parameters" thing. Evil tcl substitution rules... Since the eval is not being used in another scope that shouldn't matter. Anyway rereading the eval man page I came to the following conclusion: eval do_request $nocomplain_option $followequiv_option $location seems to work fine. The 'too many positional' propably resulted from a space in one of the values, which is good because it warned us from an error that would have turned up later otherwise. You mind trying this new syntax? cheers, til -- http://tsinger.com |
From: Grzegorz A. H. <gr...@ef...> - 2003-08-22 16:42:58
|
On 2003-08-22, Tilmann Singer <ti...@ti...> wrote: > In an attempt to clean up my inbox from permanent todo items I started > to use the feature request tracker on sourceforge here: > > http://sourceforge.net/tracker/?atid=401309&group_id=31075&func=browse > > Maybe it turns out to be useful besides burying wishes for eternity > there. By now you should already be flooded by the suggestions I keep in my mailbox. Anyway, I'm more mail based than web based. -- Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89. eFaber SL, Maria Diaz de Haro, 68, 2 http://www.efaber.net/ 48920 Portugalete, Bizkaia (SPAIN) |
From: Grzegorz A. H. <gr...@ef...> - 2003-08-22 16:16:30
|
On 2003-08-22, Tilmann Singer <ti...@ti...> wrote: > Hi, > > Wouldn't it work to simply replace [quotes with braces]? [...] Doesn't seem to. I replaced the quotes with braces (patch attached) and got: [...] > > --- do_request for http://192.168.1.50:8014/register/logout > > http status: >>302<< > > following a redirect to: http://192.168.1.50:8014/ > > > > Too many positional parameters specified > > while executing > > "do_request__arg_parser" > > (procedure "do_request" line 1) > > invoked from within > > "do_request $nocomplain_option $followequiv_option $location" > > ("eval" body line 1) > > invoked from within > > "eval {do_request $nocomplain_option $followequiv_option $location}" > > (procedure "do_request" line 134) > > invoked from within > > "do_request $LOGOUT_URL" > > ("uplevel" body line 1) > > invoked from within > > "uplevel $uplevel $to_eval " > > in script body line 0 [...] Maybe there's something more to do? I've read again the chapter about eval in my tcl manual and it says the difference between using a list and curly braces is that the latter doesn't make variable substitution immediate, which could be dangerous if the eval is going to be used in another scope. But I don't understand what this has to do with the "Too many positional parameters" thing. Evil tcl substitution rules... -- Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89. eFaber SL, Maria Diaz de Haro, 68, 2 http://www.efaber.net/ 48920 Portugalete, Bizkaia (SPAIN) |
From: Tilmann S. <ti...@ti...> - 2003-08-22 15:59:56
|
In an attempt to clean up my inbox from permanent todo items I started to use the feature request tracker on sourceforge here: http://sourceforge.net/tracker/?atid=401309&group_id=31075&func=browse Maybe it turns out to be useful besides burying wishes for eternity there. cheers, Til -- http://tsinger.com |
From: Tilmann S. <ti...@ti...> - 2003-08-22 14:24:54
|
Hi, Wouldn't it work to simply replace eval "do_request $nocomplain_option $followequiv_option $location" with eval {do_request $nocomplain_option $followequiv_option $location} ? I just did a simple test in tclsh which indicated that this should work, since then the variables get substituted during the eval run, not before which should work as well (and looks cleaner to me anyway). Unfortunately the selftests can't cover these things since they require interaction with a server, but if the fix above works for you feel free to commit it. cheers, Til -- http://tsinger.com |
From: Grzegorz A. H. <gr...@ef...> - 2003-08-22 11:58:57
|
Hi. I'm working now on an intranet for a client of us, and the restructuration led to a few new pages and redirections. These new redirections make tclwebtest fail testing units. The failure consists on a redirected url having a semicolon. The semicolon is parsed by eval as a command separation, thus, you get this output in the log: > [...] > --- do_request for http://192.168.1.50:8014/a-gastos/request-ae-2 > http status: >>302<< > following a redirect to: request-planning-travel?id=330&from=sel_new;one_req > --- do_request for http://192.168.1.50:8014/a-gastos/request-planning-travel?id=330&from=sel_new > http status: >>200<< > > invalid command name "one_req" > while executing > "one_req" > ("eval" body line 1) > invoked from within > "eval "do_request $nocomplain_option $followequiv_option $location"" > (procedure "do_request" line 134) > invoked from within > [...] As you can see, the `one_req' part of the url is parsed as a command. I didn't find any other way to solve this than create a temporary list for eval to use it. This way, parameters can have characters which eval could process with another meaning, like the semicolon. Til, are you ok with this patch? Is there any easier way to go around this? Gordon Molek, could you try this patch against your Apache server with httpauth and see if I have broken something? The patch works fine with tclwebtest's selftest directory and my own batch of unit tests, but I don't have any Apache to play. -- Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89. eFaber SL, Maria Diaz de Haro, 68, 2 http://www.efaber.net/ 48920 Portugalete, Bizkaia (SPAIN) |
From: Grzegorz A. H. <gr...@ef...> - 2003-08-18 09:12:17
|
On 2003-08-08, Gordon Molek <gor...@ea...> wrote: > Secondly, I am still having trouble with globals. [...] > > #! /cygdrive/c/tcl/bin/tclsh.exe > proc dumb_proc {} { > set myvar 4 > puts "The value of the local variable is $myvar" > > global myglobalvar > puts "The value of the global variable is $myglobalvar" > } > > set myglobalvar 79 > dumb_proc > > [...] Does tclwebtest do something that interferes with global > variables? [...] Yes it does. Basically the first thing you run is in the global namespace, `set myglobalvar 79' therefore sets a global variable. However, when you run the same script from tclwebtest, it's tclwebtest which is running in the global namespace, and your script is being run in another namespace because it is being run inside an `eval'. Maybe tclwebtest could be modified to run inside a custom namespace and then run the script with an `upvar' instead. Til, what do you think? Anyway, the solution to your problem is easy, before `set myglobalvar 79' put another `global myglobalvar' and it will work as expected: $ ./tclwebtest test ----- START: test at [18/ago/2003:10:57:59] ----- The value of the local variable is 4 The value of the global variable is 79 ----- SUCCESS: test (took 0s) ----- DURATION: 0 -- Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89. eFaber SL, Maria Diaz de Haro, 68, 2 http://www.efaber.net/ 48920 Portugalete, Bizkaia (SPAIN) |
From: Gordon M. <gor...@ea...> - 2003-08-08 11:58:41
|
Distinguisehd members of the tclwebtest-general list. I am going to try using a different e-mail address to see if this one allows me to properly respond to messages, so thanks for your patience. First, thanks to everyone for the responses to my "can't do_request" inquiry. For whatever reason, it seems to have cleared up as I am now able to receive the contents of arbitrary dotted decimal address URLs. Secondly, I am still having trouble with globals. From my previous posting, the problem is: I was trying to develop a link-walk algorithm to validate that all the links on a web-site were valid and recursion combined with a list of already visited links appeared to be the way to implement it. However, I can't seem to use globals within tclwebtest. Here's a dumb TCL script which I found on a web site somewhere that illustrates global variables: #! /cygdrive/c/tcl/bin/tclsh.exe proc dumb_proc {} { set myvar 4 puts "The value of the local variable is $myvar" global myglobalvar puts "The value of the global variable is $myglobalvar" } set myglobalvar 79 dumb_proc As expected, when run, it produces the following output: $ ./global.tcl The value of the local variable is 4 The value of the global variable is 79 However, if I try to run it using tclwebtest (without the "#! /cygdrive/c/tcl/bin/tclsh.exe" line, I get the following: $ ../tclwebtest global.test ----- START: global.test at [30/Jul/2003:07:52:51] ----- The value of the local variable is 4 can't read "myglobalvar": no such variable while executing "puts "The value of the global variable is $myglobalvar"" (procedure "dumb_proc" line 6) invoked from within "dumb_proc" (file "global.test" line 10) invoked from within "source global.test" ("uplevel" body line 3) invoked from within "uplevel $uplevel $to_eval " in "global.test" line 10: puts "The value of the global variable is $myglobalvar" } set myglobalvar 79 dumb_proc ----- FAILED: global.test (took 1s) ----- DURATION: 1 1 of 1 tests FAILED: global.test Does tclwebtest do something that interferes with global variables? I have also played around with upvar with the following test: proc dumb_proc {} { set myvar 4 puts "The value of the local variable is $myvar" upvar "#0" myglobalvar mylocalvar puts "The value of the global variable is $mylocalvar" set mylocalvar 69 } set myglobalvar 79 dumb_proc puts "The value of the global variable is now $myglobalvar" Which generates the following errors: ----- START: upvar.test at [08/Aug/2003:06:55:55] ----- The value of the local variable is 4 can't read "mylocalvar": no such variable while executing "puts "The value of the global variable is $mylocalvar"" (procedure "dumb_proc" line 6) invoked from within "dumb_proc" (file "upvar.test" line 11) invoked from within "source upvar.test" ("uplevel" body line 3) invoked from within "uplevel $uplevel $to_eval " in "upvar.test" line 11: set mylocalvar 69 } set myglobalvar 79 dumb_proc ----- FAILED: upvar.test (took 0s) ----- DURATION: 0 1 of 1 tests FAILED: upvar.test Again, when run under "straight" TCL it works as expected: $ ./upvar.tcl The value of the local variable is 4 The value of the global variable is 79 The value of the global variable is now 69 Thanks in advance, Gordon Molek |
From: Tilmann S. <ti...@ti...> - 2003-08-07 15:19:22
|
* Molek, Gordon <GM...@ze...> [20030724 15:00]: > My test case is very simple (based on one of the self-test files > that came with the package): > > set URL1 "http://www.google.com" > set URL2 "http://216.239.39.99" Did you try it with any other website than google? Maybe there is some redirection weirdness involved caused by their effort to send you to a country specific version of their site - e.g. from some providers in Austria I'm getting redirected to www.google.at, from others not. cheers, Til -- http://tsinger.com |
From: Grzegorz A. H. <gr...@ef...> - 2003-07-30 14:28:40
|
On 2003-07-30, "Molek, Gordon" <GM...@ze...> wrote: > The above fix seems to solve the problem with one additional > change, basically surrounding the "$query_key_values" argument > with curly braces, e.g., "{$query_key_values}". Fine, commited with curly braces. -- Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89. eFaber SL, Maria Diaz de Haro, 68, 2 http://www.efaber.net/ 48920 Portugalete, Bizkaia (SPAIN) |
From: Molek, G. <GM...@ze...> - 2003-07-30 12:59:02
|
Hi, it's me again. :-) I was trying to develop a link-walk algorithm to validate that all the links on a web-site were valid and recursion combined with a list of already visited links appeared to be the way to implement it. However, I can't seem to use globals within tclwebtest. Here's a dumb TCL script which I found on a web site somewhere that illustrates global variables: #! /cygdrive/c/tcl/bin/tclsh.exe proc dumb_proc {} { set myvar 4 puts "The value of the local variable is $myvar" global myglobalvar puts "The value of the global variable is $myglobalvar" } set myglobalvar 79 dumb_proc As expected, when run, it produces the following output: $ ./global.tcl The value of the local variable is 4 The value of the global variable is 79 However, if I try to run it using tclwebtest (without the "#! /cygdrive/c/tcl/bin/tclsh.exe" line, I get the following: $ ../tclwebtest global.test ----- START: global.test at [30/Jul/2003:07:52:51] ----- The value of the local variable is 4 can't read "myglobalvar": no such variable while executing "puts "The value of the global variable is $myglobalvar"" (procedure "dumb_proc" line 6) invoked from within "dumb_proc" (file "global.test" line 10) invoked from within "source global.test" ("uplevel" body line 3) invoked from within "uplevel $uplevel $to_eval " in "global.test" line 10: puts "The value of the global variable is $myglobalvar" } set myglobalvar 79 dumb_proc ----- FAILED: global.test (took 1s) ----- DURATION: 1 1 of 1 tests FAILED: global.test Does tclwebtest do something that interferes with global variables? Thanks, Gordon Molek |
From: Molek, G. <GM...@ze...> - 2003-07-30 12:52:02
|
On 2003-07-28, "Grzegorz Adam Hankiewicz" <gradha@ef...> wrote: >On 2003-07-25, "Molek, Gordon" <GMolek@ze...> wrote: > > Ok, here's another issue I just hit. If I have a password > > protected web page, I can use http_auth to set the login and > > password and I'll get an initial 401 error, and tclwebtest > > will retry with the authentication data and the page will load. > > So far so good. > > > > However, if I have a form on that page and try to post the form, > > the post will generate a 401 error, but tclwebtest doesn't re-post > > the form with the authentication data, but rather does a "get" > > of the data which results in a 404 error. > > Looks like an omission. Does the following patch make it work? > > Index: lib/tclwebtest.tcl > =================================================================== > RCS file: /cvsroot/tclwebtest/tclwebtest/lib/tclwebtest.tcl,v > retrieving revision 1.40 > diff -u -r1.40 tclwebtest.tcl > --- lib/tclwebtest.tcl 4 Jun 2003 17:40:38 -0000 1.40 > +++ lib/tclwebtest.tcl 28 Jul 2003 07:23:34 -0000 > @@ -2329,7 +2329,7 @@ > if { $inject_string != "" } { > set ::tclwebtest::http_auth_string $inject_string > log "Retrying url with preset authentication" > - eval "do_request $nocomplain_option $followequiv_option $url" > + eval "do_request $nocomplain_option $followequiv_option $url >$query_key_values" > } else { > log "This url requires http authentication set through the http_auth >command" > eval $failure_treatement > > -- > Grzegorz Adam Hankiewicz, gradha@ef.... Tel: +34-94-472 35 89. > eFaber SL, Maria Diaz de Haro, 68, 2 http://www.efaber.net/ > 48920 Portugalete, Bizkaia (SPAIN) First, let me apologize for not being able to respond properly in threads, but I have yet to receive any of the mailing list e-mails in my in-box. I don't know if they're being filtered somewhere or what. The above fix seems to solve the problem with one additional change, basically surrounding the "$query_key_values" argument with curly braces, e.g., "{$query_key_values}". Thanks, Gordon Molek |
From: Grzegorz A. H. <gr...@ef...> - 2003-07-30 08:17:45
|
When using [field select -index whatever], it would be nice if this returned the selected text. The purpose of this would be selecting something from the select at random, saving the text in a variable, and check that the selected text appears somewhere in the next web page after the form has been submited. It would be useful to avoid using many text constants in the test units (instead of a range and loop) and for forms which extract data from databases where you don't know the text. In the latter case some mechanism should be added to maybe let the user get the number of entries the select has, which could be checked against some value or used as limit for [field select -index [expr round(rand()*limit)] -- Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89. eFaber SL, Maria Diaz de Haro, 68, 2 http://www.efaber.net/ 48920 Portugalete, Bizkaia (SPAIN) |
From: Grzegorz A. H. <gr...@ef...> - 2003-07-28 07:30:36
|
On 2003-07-25, "Molek, Gordon" <GM...@ze...> wrote: > Ok, here's another issue I just hit. If I have a password > protected web page, I can use http_auth to set the login and > password and I'll get an initial 401 error, and tclwebtest > will retry with the authentication data and the page will load. > So far so good. > > However, if I have a form on that page and try to post the form, > the post will generate a 401 error, but tclwebtest doesn't re-post > the form with the authentication data, but rather does a "get" > of the data which results in a 404 error. Looks like an omission. Does the following patch make it work? Index: lib/tclwebtest.tcl =================================================================== RCS file: /cvsroot/tclwebtest/tclwebtest/lib/tclwebtest.tcl,v retrieving revision 1.40 diff -u -r1.40 tclwebtest.tcl --- lib/tclwebtest.tcl 4 Jun 2003 17:40:38 -0000 1.40 +++ lib/tclwebtest.tcl 28 Jul 2003 07:23:34 -0000 @@ -2329,7 +2329,7 @@ if { $inject_string != "" } { set ::tclwebtest::http_auth_string $inject_string log "Retrying url with preset authentication" - eval "do_request $nocomplain_option $followequiv_option $url" + eval "do_request $nocomplain_option $followequiv_option $url $query_key_values" } else { log "This url requires http authentication set through the http_auth command" eval $failure_treatement -- Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89. eFaber SL, Maria Diaz de Haro, 68, 2 http://www.efaber.net/ 48920 Portugalete, Bizkaia (SPAIN) |
From: Molek, G. <GM...@ze...> - 2003-07-25 16:03:19
|
Ok, here's another issue I just hit. If I have a password protected web page, I can use http_auth to set the login and password and I'll get an initial 401 error, and tclwebtest will retry with the authentication data and the page will load. So far so good. However, if I have a form on that page and try to post the form, the post will generate a 401 error, but tclwebtest doesn't re-post the form with the authentication data, but rather does a "get" of the data which results in a 404 error. Gordon Molek |
From: Grzegorz A. H. <gr...@ef...> - 2003-07-24 13:40:15
|
On 2003-07-24, "Molek, Gordon" <GM...@ze...> wrote: > [...] > So that I attempt the dotted decimal URL request first (or only > try the dotted decimal URL request), it doesn't work. Could you please define better what `doesn't work' means? What's the output? Any error messages? The problem is I'm running both of your test cases successfully and their output is equal with the exception that the IP url shows a slightly different page with one link more: ----- START: test at [24/jul/2003:15:32:56] ----- --- do_request for http://216.239.39.99 http status: >>200<< DEBUG: found a link: Images </imghp?hl=en&tab=wi&ie=UTF-8> DEBUG: found a link: Groups </grphp?hl=en&tab=wg&ie=UTF-8> DEBUG: found a link: Directory </dirhp?hl=en&tab=wd&ie=UTF-8> DEBUG: found a link: News </nwshp?hl=en&tab=wn&ie=UTF-8> DEBUG: found a link: Advanced Search </advanced_search?hl=en> DEBUG: found a link: Preferences </preferences?hl=en> DEBUG: found a link: Language Tools </language_tools?hl=en> DEBUG: found a link: Advertise with Us </ads/> DEBUG: found a link: Business Solutions </services/> DEBUG: found a link: Services & Tools </options/> DEBUG: found a link: Jobs, Press, & Help </about.html> DEBUG: found a link: Go to Google.com <http://www.google.com/ncr> --- do_request for http://www.google.com http status: >>200<< DEBUG: found a link: Images </imghp?hl=en&tab=wi&ie=UTF-8> DEBUG: found a link: Groups </grphp?hl=en&tab=wg&ie=UTF-8> DEBUG: found a link: Directory </dirhp?hl=en&tab=wd&ie=UTF-8> DEBUG: found a link: News </nwshp?hl=en&tab=wn&ie=UTF-8> DEBUG: found a link: Advanced Search </advanced_search?hl=en> DEBUG: found a link: Preferences </preferences?hl=en> DEBUG: found a link: Language Tools </language_tools?hl=en> DEBUG: found a link: Advertise with Us </ads/> DEBUG: found a link: Business Solutions </services/> DEBUG: found a link: Services & Tools </options/> DEBUG: found a link: Jobs, Press, & Help </about.html> ----- SUCCESS: test (took 1s) ----- DURATION: 1 Maybe the problem is external to tclwebtest and related to your platform|setup, like a DNS problem or something? I'm using Suse Linux 8.1 here through company NAT+firewall. -- Grzegorz Adam Hankiewicz, gr...@ef.... Tel: +34-94-472 35 89. eFaber SL, Maria Diaz de Haro, 68, 2 http://www.efaber.net/ 48920 Portugalete, Bizkaia (SPAIN) |
From: Molek, G. <GM...@ze...> - 2003-07-24 12:58:52
|
I just recently downloaded tclwebtest, the ChangeLog file shows -- Release 0.3 2003-05-26 --- My test case is very simple (based on one of the self-test files that came with the package): set URL1 "http://www.google.com" set URL2 "http://216.239.39.99" do_request $URL1 link reset_current while {![catch {link find -next}]} { debug "found a link: [link get_text] <[link get_url]>" } do_request $URL2 link reset_current while {![catch {link find -next}]} { debug "found a link: [link get_text] <[link get_url]>" } If I run it as above, both do_requests work. If swap URL1 and URL2, e.g., set URL2 "http://www.google.com" set URL1 "http://216.239.39.99" do_request $URL1 link reset_current while {![catch {link find -next}]} { debug "found a link: [link get_text] <[link get_url]>" } do_request $URL2 link reset_current while {![catch {link find -next}]} { debug "found a link: [link get_text] <[link get_url]>" } So that I attempt the dotted decimal URL request first (or only try the dotted decimal URL request), it doesn't work. Weird, Gordon |