HTTPCMD Help

[Bolt]

Here's a screenshot of wireshark, I'm not really sure what I'm looking for.  It is worth noting that the /post/xxx.php request doesn't show up on the wire until after the 15 second disconnect.  And it's all addressed to UDP to 255.255.255.255?  I can't find any source or destination containing the server's IP in the time period involved here.

[Bolt]

The difference is really this pronounced.  Check out the Trend View attached.  Same request to the same server, same response, one via HTTPCMD, the other via OPENTCP, STREAMOUT, STREAMIN, CLOSE.

[Andrew S]

Make sure you have the IP address formatted correctly in D300. Each octet is a byte so for instance if your server IP address is 192.168.12.34 the memory locations would contain:
D300:UB3 - 192
D300:UB2 - 168
D300:UB1 - 12
D300:UB0 - 34
The native equivalent value of this IP address would be -1062728670

[Bolt]

IP address is correct.

My SL3 via STREAMOUT is

Code: [Select]

"GET http://" FmtInt(D300,ipaddr) "/post/weather.php" "$0D$0A" response into PLC within 1/2 second

My SL3 via HTTPCMD is

Code: [Select]

/post/weather.php response into PLC over 15 seconds

[Andrew S]

Do you have any filtering switched on for the Wireshark capture or display? There are two - one you set when you set the interface you want to monitor, and the other's to filter the captured data once you start capturing.
The best way to set up Wireshark is to use "host 192.168.0.10" in the capture filter and then don't filter the display (at least initially). If you want to run a capture and then send it over I'll be happy to look at it for you. PM me if you're interested.

[Andrew S]

Looking again at the trace screenshot, that's probably a logger message. It's not the GET - that's a TCP message (the one you mentioned is UDP). Take a look at the TCP message at the top of the screen - is that relevant?

[BobO]

Starting to think there is a bug. We've had another report that sounds curiously similar. Looking at it now.

[Andrew S]

This might (or might not) be relevant but when I initially started using HTTPCMD I was having trouble connecting to the server. It turned out that if I added a PING first it worked just fine. Here's the thread I started about it: https://forum.hosteng.com/index.php/topic,2649.0.html

[BobO]

The issue was in the chunk handling. Not sure how this escaped, because it appears that chunking was always going to be a problem. I know we tested with some chunked sites, but apparently need to add some more.

The difficulty is that there are at least 3 different ways the response payload can be terminated. Trying to handle them all in a single asynchronous state handler is surprisingly awkward.

[Bolt]

This might (or might not) be relevant but when I initially started using HTTPCMD I was having trouble connecting to the server. It turned out that if I added a PING first it worked just fine. Here's the thread I started about it: https://forum.hosteng.com/index.php/topic,2649.0.html

I was always PINGing before the HTTPCMD, or OPENTCP, either way.  Thanks for the re-read, I vaguely remembered that post.

The issue was in the chunk handling. Not sure how this escaped, because it appears that chunking was always going to be a problem. I know we tested with some chunked sites, but apparently need to add some more.

The difficulty is that there are at least 3 different ways the response payload can be terminated. Trying to handle them all in a single asynchronous state handler is surprisingly awkward.

Cool, good to know I wasn't crazy afterall.

Don't forget to remove the existing TCP connection option, https://forum.hosteng.com/index.php/topic,2649.msg21567.html#msg21567

But, I don't think the chunk issue applies to me?  I'm just trying to read a <300 character string back into the BRX.

[BobO]

But, I don't think the chunk issue applies to me?  I'm just trying to read a <300 character string back into the BRX.

It's a payload encoding format that some servers use. Has nothing to do with the length of the payload.