[Bug-wget] Using --post-data vs GET is much slower

[Richard van Katwijk]

Hi,

I have a website that requires authentication to access it. I have
(temporarily) set the authentication subroutine up to allow the
username/password to be passed in via both POST and GET.

I am now using wget to try a see how long the process takes, ie passing the
parameters to the login page, and then receive back all components of the
resulting page (redirect after login to the home page) using '-p'

I have two identical tests, differing only in that one sends the login
credentials via --post-data and the other passing them in the url itself, as
per examples below:

POST:
(/usr/bin/time -p /usr/bin/wget -q -p -O authentication_post.txt
--keep-session-cookies --save-cookies cookies.txt --post-data 'email=
address@hidden&password=some_password' https://www.mysite.com/login) 2>&1 |
/bin/grep real | /usr/bin/cut -d ' ' -f 2

GET:
(/usr/bin/time -p /usr/bin/wget -q -p -O authentication_get.txt
--keep-session-cookies --save-cookies cookies.txt
https://www.mysite.com/address@hidden&password=some_password)
2>&1 | /bin/grep real | /usr/bin/cut -d ' ' -f 2

I have:
- confirmed that the output from both is the same (ie they do both login
successfully and both redirect to and return the same page)
- tried this with normal http as well as https

The GET seemt to return in under 1 second consistently, the POST is
consistently around 5 seconds - a big difference. I can confirm that the GET
is more realistic - doing this on a real browser, the authentication and
redirect id very quick.

I have also watched the wget tests in action by removing the 'quiet' switch
-q, and all the timing stuff around the actual test - in the GET the output
is very fast, in the POST is so much slower you can almost read it as wget
outputs it to the screen.

Question is, why is using --post-data significantly slower than the
equivalent with GET? I dont think its dns related? And the docs say the
post-data is NOT passed to every page item call, so that shouldnt be it. I
am at a loss.....

Thanks,
Richard