Re: [WebDNA] TCPConnect example doesn't work

This WebDNA talk-list message is from

2017


It keeps the original formatting.
numero = 113464
interpreted = N
texte = 1059 --Apple-Mail=_DCBA8E54-6FB1-4D33-8A5D-BC3FDEE2352D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ken, I've run into this problem in the past. You can use cURL to pre-flight = your endpoint. I have a basic function that works for the situations I = need it for and you're welcome to grab it and use it http://www.network13.net/webdna_code_curl_redirects.dna = Maybe WebDNA TCPConnect will be improved to follow redirects in the = future, but for now, we DIY, which I don't really have a problem with, = so long as it works. Mike > On Mar 9, 2017, at 11:10 AM, Kenneth Grome = wrote: >=20 > 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. >=20 > 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. >=20 > =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. >=20 > 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. >=20 > 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. >=20 > Regards, > Kenneth Grome > WebDNA Solutions > http://www.webdnasolutions.com > Web Database Systems and Linux Server Administration >=20 >=20 >=20 >=20 >=20 >=20 >=20 > 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=99s >> always functioned=E2=80=A6 and I believe there has been some feature >> requests to allow tcpconnect to follow redirects. >>=20 >> I think in PHP curl you have to specify to follow redirects. >>=20 >> So, a workaround could be to use curl I guess. >>=20 >> Donovan >>=20 >>=20 >>=20 >>=20 >> On Mar 9, 2017, at 11:36 AM, Kenneth Grome >> wrote: >>=20 >>> It doesn't follow the redirect like a POST tcpconnect does,=20 >>> that's why I said it's not working properly. >>>=20 >>> Do tcpconnects only follow redirects when using POST but not >>> when using GET? IF so, this should be documented. >>>=20 >>> Or is there actually something wrong with the example I=20 >>> posted that's preventing it from following the redirect? >>>=20 >>> You can easily compare the two examples below. I would=20 >>> expect them to return the same results since they are=20 >>> requesting the same page, but they do not: >>>=20 >>>=20 >>> [tcpconnect host=3Dwww.webdna.us&port=3D80] [tcpsend]GET / >>> HTTP/1.0[unurl]%0D%0A%0D%0A[/unurl][/tcpsend] [/tcpconnect] >>>=20 >>>=20 >>> [text]host=3Dwww.webdna.us[/text] [text]path=3D/[/text]=20 >>> [text]n=3D[unurl]%0D%0A[/unurl][/text] [text]content=3D[/text]=20 >>> [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][!]=20 >>> [/!]Content-Type: text/namevalue[n][!] [/!]Content-Length: >>> [countchars][content][/countchars][n][n][!]=20 >>> [/!][content][n][!] [/!][/tcpsend] [/tcpconnect] >>>=20 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Bottom line: I still think something's wrong, either with >>> the internal code that interprets GET tcpconnects or with the >>> WebDNA syntax itself. >>>=20 >>> Regards, Kenneth Grome WebDNA Solutions=20 >>> http://www.webdnasolutions.com Web Database Systems and Linux >>> Server Administration >>>=20 >>>=20 >>>=20 >>> 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. >>>>=20 >>>> Donovan >>>>=20 >>>>=20 >>>>=20 >>>> On Mar 9, 2017, at 9:59 AM, Kenneth Grome >>>> wrote: >>>>=20 >>>>> This sample code (from the webdna.us website) doesn't >>>>> work: >>>>>=20 >>>>> [tcpconnect host=3Dwww.webdna.us&port=3D80] [tcpsend]GET / >>>>> HTTP/1.0[unurl]%0D%0A%0D%0A[/unurl][/tcpsend]=20 >>>>> [/tcpconnect] >>>>>=20 >>>>> What's missing from this code ... or what's incorrect >>>>> about? Or don't tcpconnects work with method=3DGET any >>>>> more? >>>>>=20 >>>>> Something's wrong with it because this is what it >>>>> produces: >>>>>=20 >>>>> 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=3D27 Content-Length: 1 Vary: >>>>> Accept-Encoding,User-Agent Connection: close >>>>> Content-Type: text/html >>>>>=20 >>>>> Regards, Kenneth Grome WebDNA Solutions=20 >>>>> http://www.webdnasolutions.com Web Database Systems and >>>>> Linux Server Administration >>>>>=20 >>>>>=20 >>>>> --------------------------------------------------------- >>>>>=20 >>>>>=20 > This message is sent to you because you are subscribed to >>>>> the mailing list . To unsubscribe, E-mail >>>>> to: archives: >>>>> http://mail.webdna.us/list/talk@webdna.us Bug Reporting: >>>>> support@webdna.us >>>>=20 >>>> ---------------------------------------------------------=20 >>>> This message is sent to you because you are subscribed to=20 >>>> the mailing list . To unsubscribe, E-mail >>>> to: archives: >>>> http://mail.webdna.us/list/talk@webdna.us Bug Reporting: >>>> support@webdna.us >>>>=20 >>> ---------------------------------------------------------=20 >>> This message is sent to you because you are subscribed to the >>> mailing list . To unsubscribe, E-mail to: >>> archives: >>> http://mail.webdna.us/list/talk@webdna.us Bug Reporting: >>> support@webdna.us >>=20 >> --------------------------------------------------------- This >> message is sent to you because you are subscribed to the >> mailing list . To unsubscribe, E-mail to: >> archives: >> http://mail.webdna.us/list/talk@webdna.us Bug Reporting: >> support@webdna.us >>=20 >=20 > Sincerely, > Kenneth Grome >=20 > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > 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 . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us --Apple-Mail=_DCBA8E54-6FB1-4D33-8A5D-BC3FDEE2352D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ken,

I've = run into this problem in the past.  You can use cURL to pre-flight = your endpoint.  I have a basic function that works for the = situations I need it for and you're welcome to grab it and use = it
http://www.network13.net/webdna_code_curl_redirects.dna

Maybe WebDNA = TCPConnect will be improved to follow redirects in the future, but for = now, we DIY, which I don't really have a problem with, so long as it = works.


Mike


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=99s
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


---------------------------------------------------------


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

--------------------------------------------------------- = 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

= --Apple-Mail=_DCBA8E54-6FB1-4D33-8A5D-BC3FDEE2352D-- . Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] TCPConnect example doesn't work (christophe.billiottet@webdna.us 2017)
  2. Re: [WebDNA] TCPConnect example doesn't work (Kenneth Grome 2017)
  3. Re: [WebDNA] TCPConnect example doesn't work (Michael Davis 2017)
  4. Re: [WebDNA] TCPConnect example doesn't work (Kenneth Grome 2017)
  5. Re: [WebDNA] TCPConnect example doesn't work (Michael Davis 2017)
  6. Re: [WebDNA] TCPConnect example doesn't work (Kenneth Grome 2017)
  7. Re: [WebDNA] TCPConnect example doesn't work (Donovan Brooke 2017)
  8. Re: [WebDNA] TCPConnect example doesn't work (Kenneth Grome 2017)
  9. Re: [WebDNA] TCPConnect example doesn't work (Donovan Brooke 2017)
  10. [WebDNA] TCPConnect example doesn't work (Kenneth Grome 2017)
1059 --Apple-Mail=_DCBA8E54-6FB1-4D33-8A5D-BC3FDEE2352D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ken, I've run into this problem in the past. You can use cURL to pre-flight = your endpoint. I have a basic function that works for the situations I = need it for and you're welcome to grab it and use it http://www.network13.net/webdna_code_curl_redirects.dna = Maybe WebDNA TCPConnect will be improved to follow redirects in the = future, but for now, we DIY, which I don't really have a problem with, = so long as it works. Mike > On Mar 9, 2017, at 11:10 AM, Kenneth Grome = wrote: >=20 > 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. >=20 > 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. >=20 > =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. >=20 > 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. >=20 > 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. >=20 > Regards, > Kenneth Grome > WebDNA Solutions > http://www.webdnasolutions.com > Web Database Systems and Linux Server Administration >=20 >=20 >=20 >=20 >=20 >=20 >=20 > 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=99s >> always functioned=E2=80=A6 and I believe there has been some feature >> requests to allow tcpconnect to follow redirects. >>=20 >> I think in PHP curl you have to specify to follow redirects. >>=20 >> So, a workaround could be to use curl I guess. >>=20 >> Donovan >>=20 >>=20 >>=20 >>=20 >> On Mar 9, 2017, at 11:36 AM, Kenneth Grome >> wrote: >>=20 >>> It doesn't follow the redirect like a POST tcpconnect does,=20 >>> that's why I said it's not working properly. >>>=20 >>> Do tcpconnects only follow redirects when using POST but not >>> when using GET? IF so, this should be documented. >>>=20 >>> Or is there actually something wrong with the example I=20 >>> posted that's preventing it from following the redirect? >>>=20 >>> You can easily compare the two examples below. I would=20 >>> expect them to return the same results since they are=20 >>> requesting the same page, but they do not: >>>=20 >>>=20 >>> [tcpconnect host=3Dwww.webdna.us&port=3D80] [tcpsend]GET / >>> HTTP/1.0[unurl]%0D%0A%0D%0A[/unurl][/tcpsend] [/tcpconnect] >>>=20 >>>=20 >>> [text]host=3Dwww.webdna.us[/text] [text]path=3D/[/text]=20 >>> [text]n=3D[unurl]%0D%0A[/unurl][/text] [text]content=3D[/text]=20 >>> [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][!]=20 >>> [/!]Content-Type: text/namevalue[n][!] [/!]Content-Length: >>> [countchars][content][/countchars][n][n][!]=20 >>> [/!][content][n][!] [/!][/tcpsend] [/tcpconnect] >>>=20 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Bottom line: I still think something's wrong, either with >>> the internal code that interprets GET tcpconnects or with the >>> WebDNA syntax itself. >>>=20 >>> Regards, Kenneth Grome WebDNA Solutions=20 >>> http://www.webdnasolutions.com Web Database Systems and Linux >>> Server Administration >>>=20 >>>=20 >>>=20 >>> 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. >>>>=20 >>>> Donovan >>>>=20 >>>>=20 >>>>=20 >>>> On Mar 9, 2017, at 9:59 AM, Kenneth Grome >>>> wrote: >>>>=20 >>>>> This sample code (from the webdna.us website) doesn't >>>>> work: >>>>>=20 >>>>> [tcpconnect host=3Dwww.webdna.us&port=3D80] [tcpsend]GET / >>>>> HTTP/1.0[unurl]%0D%0A%0D%0A[/unurl][/tcpsend]=20 >>>>> [/tcpconnect] >>>>>=20 >>>>> What's missing from this code ... or what's incorrect >>>>> about? Or don't tcpconnects work with method=3DGET any >>>>> more? >>>>>=20 >>>>> Something's wrong with it because this is what it >>>>> produces: >>>>>=20 >>>>> 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=3D27 Content-Length: 1 Vary: >>>>> Accept-Encoding,User-Agent Connection: close >>>>> Content-Type: text/html >>>>>=20 >>>>> Regards, Kenneth Grome WebDNA Solutions=20 >>>>> http://www.webdnasolutions.com Web Database Systems and >>>>> Linux Server Administration >>>>>=20 >>>>>=20 >>>>> --------------------------------------------------------- >>>>>=20 >>>>>=20 > This message is sent to you because you are subscribed to >>>>> the mailing list . To unsubscribe, E-mail >>>>> to: archives: >>>>> http://mail.webdna.us/list/talk@webdna.us Bug Reporting: >>>>> support@webdna.us >>>>=20 >>>> ---------------------------------------------------------=20 >>>> This message is sent to you because you are subscribed to=20 >>>> the mailing list . To unsubscribe, E-mail >>>> to: archives: >>>> http://mail.webdna.us/list/talk@webdna.us Bug Reporting: >>>> support@webdna.us >>>>=20 >>> ---------------------------------------------------------=20 >>> This message is sent to you because you are subscribed to the >>> mailing list . To unsubscribe, E-mail to: >>> archives: >>> http://mail.webdna.us/list/talk@webdna.us Bug Reporting: >>> support@webdna.us >>=20 >> --------------------------------------------------------- This >> message is sent to you because you are subscribed to the >> mailing list . To unsubscribe, E-mail to: >> archives: >> http://mail.webdna.us/list/talk@webdna.us Bug Reporting: >> support@webdna.us >>=20 >=20 > Sincerely, > Kenneth Grome >=20 > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > 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 . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us --Apple-Mail=_DCBA8E54-6FB1-4D33-8A5D-BC3FDEE2352D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ken,

I've = run into this problem in the past.  You can use cURL to pre-flight = your endpoint.  I have a basic function that works for the = situations I need it for and you're welcome to grab it and use = it
http://www.network13.net/webdna_code_curl_redirects.dna

Maybe WebDNA = TCPConnect will be improved to follow redirects in the future, but for = now, we DIY, which I don't really have a problem with, so long as it = works.


Mike


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=99s
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


---------------------------------------------------------


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

--------------------------------------------------------- = 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

= --Apple-Mail=_DCBA8E54-6FB1-4D33-8A5D-BC3FDEE2352D-- . Michael Davis

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

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...

Related Readings:

[WebDNA] WebDNA & VPS (2009) Error Log.db --however (1997) Adding multiple items to a DB from a search. (1998) Help name our technology! (1997) Search/sort in URL Was: GuestBook example (1997) OT: Euros to Dollars (2008) WebCat hosting providers? (1997) Error Msg (1997) [/application] error? (1997) [OT] Server check please (2006) Trouble with formula.db + more explanation (1997) WebCatalog can't find database (1997) Virtual Domains (1998) PROTECT PAGES (2002) Forbidden CGI Error (1997) Migrating to NT (1997) Resetting a Formvariable (2000) [WebDNA] WebDNA future (2010) Keep away (1997) truncating email part II (1997)