Problems PUTting to LAN hardware switch.

[Sinusoidal]

Hi, I'm not convinced this is NR-specific but I am only seeing the behaviour in NR at the moment, and I really have no other better theory right now, so here goes nothing...

I have purchased an Advantech WISE-4060/LAN (http://www.advantech.com/products/da5ad5b2-09b9-418c-9f6a-f4a6e2f8f53a/wise-4060-lan/mod_dbee8699-e674-4600-b8aa-b1505f9065b0). I need to activate it's relays to open an entrance gate for a museum. There is a basic REST interface available for this purpose.

Using NR I have managed to GET the status of the relays. In Firefox (RestClient) and Chrome (Postman) I have managed to both GET and PUT the status of the relays. The interface receives a simple JSON structure in order to carry out switching the relays.

Example: PUT http://10.0.0.1/do_value/slot_0/ch_2 and body

 {"Ch":2,"Val":1}

That will turn on relay number 2. Setting Val to 0 turns it off again. 

There is basic auth on the interface but that is working everywhere.

So, to the issue in NR: When I use the request node with correct basic auth and the same address and body, I get: 

statusCode = 411

headers = { "server": "WISE-4000/LAN/8.1.0019", "connection": "close" } 

Needless to say nothing happens on the switch! This is where I received 200 on Chrome and Firefox and the switch was then activated.

Now 411 is usually to do with content length so I investigated that and ended up down a rabbit hole of setting various header parameters after sniffing the headers on the Chrome and Firefox solution. It hasn't helped yet, and I've gone through every difference, although I may not be setting these parameters with the right data. Not sure.

Can anybody point me in the right direction. Is something happening in Express that affects a typical (or otherwise) PUT request?

Thanks!

[Dave C-J]

Def sounds odd - if you don't set the content-length in the header we should default to doing it for you.

If you want to dig - the line where we make the request is in file 21-httprequest.js - line 146

you could insert before that     console.log("OPTS",opts);

and see what it thinks it's sending.... 

[Sinusoidal]

Hmm. Well, content-length certainly seems to be set correctly, logging as you suggest. In fact, take a look: 

OPTS Url {

  protocol: 'http:',

  slashes: true,

  auth: 'root:00000000',

  host: '10.0.0.1',

  port: null,

  hostname: '10.0.0.1',

  hash: null,

  search: null,

  query: null,

  pathname: '/do_value/slot_0/ch_2',

  path: '/do_value/slot_0/ch_2',

  href: 'http://10.0.0.1/do_value/slot_0/ch_2',

  method: 'PUT',

  headers: { 'content-type': 'application/json', 'content-length': 16 } }

BODY { Ch: 2, Val: 0 }

Thought was maybe port, but i guess that just gets set to default later on (tried changing to no effect). I'm stumped...

[steve rickus]

It's hard to see on my screen -- but from what I am able to count, it appears that the body actually contains 17 characters:

On Wednesday, September 28, 2016 at 9:09:30 AM UTC-4, Sinusoidal wrote:

Hmm. Well, content-length certainly seems to be set correctly, logging as you suggest. In fact, take a look: 

OPTS Url {

...

 headers: { 'content-type': 'application/json', 'content-length': 16 } }

BODY { Ch: 2, Val: 0 }

 Is it possible that the 411 error could be caused by a mismatch between the header content-length and the body length?

Since you've already modified the 21-httprequest.js source, I guess you could just add +1 to the content-length (around lines 112-114) and see if the error goes away...

[Sinusoidal]

When testing successfully in Chrome and Firefox, I saw that length was in fact 16 characters there. So I don't really believe in this solution, but having said that I'm pulling my hair out right now so I'll be ready to try iterating over all possible content-lengths soon...! 

[Sinusoidal]

Here's on of the headers i sniffed for a successful PUT in postman (chrome). 

1. PUT /do_value/slot_0/ch_2 HTTP/1.1
   Host: 10.0.0.1
   Connection: keep-alive
   Content-Length: 16
   User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36
   Postman-Token: 53751de3-b402-b51d-c35e-0366d6ab90f2
   Cache-Control: no-cache
   Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
   Authorization: Basic cm9vdDowMDAwMDAwMA==
   Content-Type: text/plain;charset=UTF-8
   Accept: */*
   Accept-Encoding: gzip, deflate, sdch
   Accept-Language: sv-SE,sv;q=0.8,en-US;q=0.6,en;q=0.4

I have as I said gone systematically through these and added in NR headers where possible/necessary. I've read somewhere that Origin-related issues may trigger a 411, but I don't know enough and can't find the right place to read up about it...don't know what I would set for Origin.

[Sinusoidal]

Ok. I just went in to lines 112 and 114 of 21-httprequest.js and swapped content-type for Content-Type. And IT WORKED! Couldn't really believe it, so I switched back and forth a few times to confirm. It's a case issue on Content-Type...! 

What do the standards say about this sort of thing? Is it on NR to handle this, or should I turn to Advantech and tell them to be more generous?

[Nicholas O'Leary]

HTTP Header fields names are case insensitive - https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2

Nick

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.

To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/c506906a-aed0-4744-abf7-0a32e3faefac%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Sinusoidal]

Yes, thought so. Btw I meant Content-Length not Content-Type. So it's on Advantech to fix. Until then I guess I'll have to keep that case change in the source, not nice. Thanks anyway!

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.

To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.

[Dave C-J]

You should be able to set Content-Length in msg.headers ouside the node (and pass it in with the msg.payload)... albeit you would have to do the length calculation yourself... (or indeed leave the hack in :-)

Well found !