On =Mar 9, 2017, at 11:10 AM, Kenneth Grome <ken@webdnasolutions.com> wrote:I =haven't used GET tcpconnect in a very long time so maybe you're
right. I don't really remember having any problems with =it
before, but something is definitely wrong when the file =clearly
exists in the exact location specified yet it =won't GET it.
I do know that POST =tcpconnects often require the host to be
specified in two =places: in the tcpconnect tag and also inside the
tcpsend =context.
=46rom what I recall when I =learned about this 'two hosts' issue a
long time ago, this =was a 'sometimes' requirement that depended
upon the =server receiving the request. It's been a while since I
ran into it, so maybe putting the host in both places is a
requirement in all POST tcpconnects now.
Unfortunately there is almost nothing in the online docs =that
mentions any of this. I would hate to be a new =user who doesn't
know all these undocumented requirements =because after trying and
failing to get the published =examples to work properly I might
conclude that the =software is not that great.
P.S. I didn't =use cURL here because my POST tcpconnects are
working =fine, but I've used it before and it seems to work well.
Regards,
Kenneth Grome
WebDNA =Solutions
http://www.webdnasolutions.com
Web Database =Systems and Linux Server Administration
On 03/09/2017 11:45 AM, Donovan Brooke wrote:Ahh=E2=80=A6 well, If =memory serves.. I think that=E2=80=99s the way it=E2=80=99sThis =message is sent to you because you are subscribed to
always functioned=E2=80=A6 and I believe there has been some =feature
requests to allow tcpconnect to follow =redirects.
I think in PHP curl you have to =specify to follow redirects.
So, a =workaround could be to use curl I guess.
Donovan
On Mar 9, 2017, at 11:36 AM, Kenneth Grome
<ken@webdnasolutions.com> wrote:It doesn't follow the =redirect like a POST tcpconnect does,
that's why I said =it's not working properly.
Do tcpconnects =only follow redirects when using POST but not
when using =GET? IF so, this should be documented.
Or is there actually something wrong with the example I
posted that's preventing it from following the redirect?
You can easily compare the two examples below. = I would
expect them to return the same results =since they are
requesting the same page, but they do =not:
[tcpconnect =host=3Dwww.webdna.us&port=3D80] [tcpsend]GET /
HTTP/1.0[unurl]%0D%0A%0D%0A[/unurl][/tcpsend] =[/tcpconnect]
[text]host=3Dwww.webdna.us[/text] [text]path=3D/[/text]
[text]n=3D[unurl]%0D%0A[/unurl][/text] [text]content=3D[/text] =
[tcpconnect host=3D[host]&port=3D80] [tcpsend]POST =[path]
HTTP/1.0[n][!] [/!]Host: [host][n][!] =[/!]User-Agent:
Mozilla/4.0 (compatible; MSIE 5.01; =Windows NT 5.0)[n][!]
[/!]Content-Type: =text/namevalue[n][!] [/!]Content-Length:
[countchars][content][/countchars][n][n][!]
[/!][content][n][!] [/!][/tcpsend] [/tcpconnect]
I had the same problem when =using both types of tcpconnects
to request pages from = two of my sites, each of which is on a
different =server. The POST versions worked fine every time,
=but the GET versions always failed.
And in =my tests I specifically requested an existing file,
but =instead of receiving it in the GET versions I always got
a =404 error while the POST versions received the specified
file.
Bottom line: I still =think something's wrong, either with
the internal code =that interprets GET tcpconnects or with the
WebDNA syntax =itself.
Regards, Kenneth Grome WebDNA =Solutions
http://www.webdnasolutions.com Web Database =Systems and Linux
Server Administration
On 03/09/2017 10:39 AM, Donovan =Brooke wrote:Looks =like it=E2=80=99s working to me.. a 302 is a (temp)
redirect.
Donovan
On Mar 9, 2017, =at 9:59 AM, Kenneth Grome
<ken@webdnasolutions.com> =wrote:This sample code (from the webdna.us website) doesn't
work:
[tcpconnect =host=3Dwww.webdna.us&port=3D80] [tcpsend]GET /
HTTP/1.0[unurl]%0D%0A%0D%0A[/unurl][/tcpsend]
[/tcpconnect]
What's missing =from this code ... or what's incorrect
about? Or =don't tcpconnects work with method=3DGET any
more?
Something's wrong with it because this is what =it
produces:
HTTP/1.1 302 =Moved Temporarily Date: Thu, 09 Mar 2017
15:59:16 GMT =Server: Apache/2.2.15 (CentOS) Location:
page.dna?numero=3D2=7 Content-Length: 1 Vary:
Accept-Encoding,User-Agent =Connection: close
Content-Type: text/html
Regards, Kenneth Grome WebDNA Solutions
http://www.webdnasolutions.com Web Database Systems and
Linux Server Administration
-----------------------------------------------------------------------------------------------------------=-------the mailing list <talk@webdna.us>. To unsubscribe, =E-mail
to: <talk-leave@webdna.us> archives:
http://mail.webdna.us/list/talk@webdna.us Bug Reporting:
support@webdna.us
---------------------------------------------------------
This message is sent to you because you are subscribed to
the mailing list <talk@webdna.us>. To unsubscribe, =E-mail
to: <talk-leave@webdna.us> archives:
http://mail.webdna.us/list/talk@webdna.us Bug Reporting:
support@webdna.us
This message is sent to you because you are =subscribed to the
mailing list <talk@webdna.us>. To =unsubscribe, E-mail to:
<talk-leave@webdna.us> =archives:
http://mail.webdna.us/list/talk@webdna.us Bug =Reporting:
support@webdna.us
--------------------------------------------------------- =This
message is sent to you because you are subscribed to =the
mailing list <talk@webdna.us>. To unsubscribe, =E-mail to:
<talk-leave@webdna.us> archives:
http://mail.webdna.us/list/talk@webdna.us Bug Reporting:
support@webdna.us
Sincerely,
Kenneth Grome
---------------------------------------------------------
This message is sent to you because you are subscribed to
the mailing list <talk@webdna.us>.
To =unsubscribe, E-mail to: <talk-leave@webdna.us>
archives: http://mail.webdna.us/list/talk@webdna.us
Bug Reporting: support@webdna.us
|
On =Mar 9, 2017, at 11:10 AM, Kenneth Grome <ken@webdnasolutions.com> wrote:I =haven't used GET tcpconnect in a very long time so maybe you're
right. I don't really remember having any problems with =it
before, but something is definitely wrong when the file =clearly
exists in the exact location specified yet it =won't GET it.
I do know that POST =tcpconnects often require the host to be
specified in two =places: in the tcpconnect tag and also inside the
tcpsend =context.
=46rom what I recall when I =learned about this 'two hosts' issue a
long time ago, this =was a 'sometimes' requirement that depended
upon the =server receiving the request. It's been a while since I
ran into it, so maybe putting the host in both places is a
requirement in all POST tcpconnects now.
Unfortunately there is almost nothing in the online docs =that
mentions any of this. I would hate to be a new =user who doesn't
know all these undocumented requirements =because after trying and
failing to get the published =examples to work properly I might
conclude that the =software is not that great.
P.S. I didn't =use cURL here because my POST tcpconnects are
working =fine, but I've used it before and it seems to work well.
Regards,
Kenneth Grome
WebDNA =Solutions
http://www.webdnasolutions.com
Web Database =Systems and Linux Server Administration
On 03/09/2017 11:45 AM, Donovan Brooke wrote:Ahh=E2=80=A6 well, If =memory serves.. I think that=E2=80=99s the way it=E2=80=99sThis =message is sent to you because you are subscribed to
always functioned=E2=80=A6 and I believe there has been some =feature
requests to allow tcpconnect to follow =redirects.
I think in PHP curl you have to =specify to follow redirects.
So, a =workaround could be to use curl I guess.
Donovan
On Mar 9, 2017, at 11:36 AM, Kenneth Grome
<ken@webdnasolutions.com> wrote:It doesn't follow the =redirect like a POST tcpconnect does,
that's why I said =it's not working properly.
Do tcpconnects =only follow redirects when using POST but not
when using =GET? IF so, this should be documented.
Or is there actually something wrong with the example I
posted that's preventing it from following the redirect?
You can easily compare the two examples below. = I would
expect them to return the same results =since they are
requesting the same page, but they do =not:
[tcpconnect =host=3Dwww.webdna.us&port=3D80] [tcpsend]GET /
HTTP/1.0[unurl]%0D%0A%0D%0A[/unurl][/tcpsend] =[/tcpconnect]
[text]host=3Dwww.webdna.us[/text] [text]path=3D/[/text]
[text]n=3D[unurl]%0D%0A[/unurl][/text] [text]content=3D[/text] =
[tcpconnect host=3D[host]&port=3D80] [tcpsend]POST =[path]
HTTP/1.0[n][!] [/!]Host: [host][n][!] =[/!]User-Agent:
Mozilla/4.0 (compatible; MSIE 5.01; =Windows NT 5.0)[n][!]
[/!]Content-Type: =text/namevalue[n][!] [/!]Content-Length:
[countchars][content][/countchars][n][n][!]
[/!][content][n][!] [/!][/tcpsend] [/tcpconnect]
I had the same problem when =using both types of tcpconnects
to request pages from = two of my sites, each of which is on a
different =server. The POST versions worked fine every time,
=but the GET versions always failed.
And in =my tests I specifically requested an existing file,
but =instead of receiving it in the GET versions I always got
a =404 error while the POST versions received the specified
file.
Bottom line: I still =think something's wrong, either with
the internal code =that interprets GET tcpconnects or with the
WebDNA syntax =itself.
Regards, Kenneth Grome WebDNA =Solutions
http://www.webdnasolutions.com Web Database =Systems and Linux
Server Administration
On 03/09/2017 10:39 AM, Donovan =Brooke wrote:Looks =like it=E2=80=99s working to me.. a 302 is a (temp)
redirect.
Donovan
On Mar 9, 2017, =at 9:59 AM, Kenneth Grome
<ken@webdnasolutions.com> =wrote:This sample code (from the webdna.us website) doesn't
work:
[tcpconnect =host=3Dwww.webdna.us&port=3D80] [tcpsend]GET /
HTTP/1.0[unurl]%0D%0A%0D%0A[/unurl][/tcpsend]
[/tcpconnect]
What's missing =from this code ... or what's incorrect
about? Or =don't tcpconnects work with method=3DGET any
more?
Something's wrong with it because this is what =it
produces:
HTTP/1.1 302 =Moved Temporarily Date: Thu, 09 Mar 2017
15:59:16 GMT =Server: Apache/2.2.15 (CentOS) Location:
page.dna?numero=3D2=7 Content-Length: 1 Vary:
Accept-Encoding,User-Agent =Connection: close
Content-Type: text/html
Regards, Kenneth Grome WebDNA Solutions
http://www.webdnasolutions.com Web Database Systems and
Linux Server Administration
-----------------------------------------------------------------------------------------------------------=-------the mailing list <talk@webdna.us>. To unsubscribe, =E-mail
to: <talk-leave@webdna.us> archives:
http://mail.webdna.us/list/talk@webdna.us Bug Reporting:
support@webdna.us
---------------------------------------------------------
This message is sent to you because you are subscribed to
the mailing list <talk@webdna.us>. To unsubscribe, =E-mail
to: <talk-leave@webdna.us> archives:
http://mail.webdna.us/list/talk@webdna.us Bug Reporting:
support@webdna.us
This message is sent to you because you are =subscribed to the
mailing list <talk@webdna.us>. To =unsubscribe, E-mail to:
<talk-leave@webdna.us> =archives:
http://mail.webdna.us/list/talk@webdna.us Bug =Reporting:
support@webdna.us
--------------------------------------------------------- =This
message is sent to you because you are subscribed to =the
mailing list <talk@webdna.us>. To unsubscribe, =E-mail to:
<talk-leave@webdna.us> archives:
http://mail.webdna.us/list/talk@webdna.us Bug Reporting:
support@webdna.us
Sincerely,
Kenneth Grome
---------------------------------------------------------
This message is sent to you because you are subscribed to
the mailing list <talk@webdna.us>.
To =unsubscribe, E-mail to: <talk-leave@webdna.us>
archives: http://mail.webdna.us/list/talk@webdna.us
Bug Reporting: support@webdna.us
DOWNLOAD WEBDNA NOW!
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...