• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
http library doesn't properly handle big response
#21
Using my http action, I now receive the expected http result data in the callback, so the errors have indeed been fixed. Thanks.

The next thing I need to do is to control the DEVICE defined in the http action.

The protocol for this device is a bit like  a generic_label but with different set of options and a state.
I am thinking of this way to get this working:

Extending the generic_label device wrapper so it can be used both for the normal generic_label protocol  and for the http_result protocol. In fact this implies that the label device wrapper for lua needs to be extended with set- and get methods needed for the http protocol. Ofc. the actions need to check that the proper combinations of parameters are provided in the rules.

What do you think of this approach?
 
Reply
#22
I would for now just create a new device. It would also be great if you could just create that generic HTTP action that just do POST and GET actions. Similar to the mail action at this point. I would like integrate such an action already.
 
Reply
#23
I already had created both the device and the action. I also created the documentation for the http action.
The action is what I have been testing with so far. However the practical benefits are very limited without the possibility to use the data and/or code in your rules.

I am not able to do PRs for some time, but I attached http.lua and http.rst.
So, if time matters, you can integrate them yourself now if you wish.

I would appreciate if you could tell me what you think if the idea to extend the label device wrapper so it can be used both for the label- and the http action.


Attached Files
.zip   http.zip (Size: 1.53 KB / Downloads: 4)
 
Reply
#24
Quote:I would appreciate if you could tell me what you think if the idea to extend the label device wrapper so it can be used both for the label- and the http action. 
I already told you, just create a new device as you already did and also create a new lua device.

Quote:The action is what I have been testing with so far. However the practical benefits are very limited without the possibility to use the data and/or code in your rules.
That depends, e.g. posting a temperature value to a webserver can be very usefull for extended logging. So instead of retreiving information, the current HTTP action is very usefull for sending information. You are covering the retrieval part.
 
Reply
#25
I now have a working version of the full lua http action with the protocol receiving the code, size, mimetype and data.

this includes:
  • The http action itself
  • A new "HTTP" devicetype, defined in protocols/protocol.h and added to lua/config.c
  • A lua wrapper for protocols with devicetype "HTTP"
  • The generic_http protocol
Documentation is still to be done.

It is running fine, but I still want to test it better.

As a reminder (at least for myself), before releasing the http action and -protocol:

  1. We still need to fix segfauts due to device string values overflowing the current 255 byte buffer, by making the size dynamic.
  2. The time out for http requests must be set higher than the current 3 seconds, or better, shoud be made configurable (within given limits).
 
Reply
#26
The HTTP action does not have a unit test yet, so i've improved it a bit and posted my version on the wiki:
https://wiki.pilight.org/action_http
 
Reply
#27
I see that you added order checks to the http action. I left those out on purpose, because imho there is no good reason for checking the order of the options in any action. If the user wishes to use a different order than you or me would do, so what?

Forgive me if I'm wrong, but I think that the order doesn't matter technically nor functionally. What is important and must be checked is that options and their values are valid and consistent.
 
Reply
#28
Quote:Forgive me if I'm wrong, but I think that the order doesn't matter technically nor functionally. What is important and must be checked is that options and their values are valid and consistent. 
That's true for all actions  Big Grin So why enforce it there? The great thing about lua modules is that you can easily remove them.
 
Reply
#29
Yes the checks can easily be removed, but the point I was trying tp make is why do the effort of putting in those checks in the first place?

As I said in my post:
Quote:imho there is no good reason for checking the order of the options in any action

It is  just extra code that adds nothing useful in my opnion.

So what I implicitly was trying to say is to remove all order checking from all existing actions and not adding them to newly created actions.
 
Reply
#30
Maybe that's true. Can you do a PR that does just that?
 
Reply
  


Possibly Related Threads...
Thread Author Replies Views Last Post
  ][solved]Segfault when retrieving big chunked http message Niek 21 5,306 11-29-2018, 03:17 PM
Last Post: curlymo
  http code 301 causes segfault Niek 3 3,201 08-14-2018, 06:57 PM
Last Post: curlymo
  no callback on some http requests Niek 20 5,916 07-28-2018, 10:22 AM
Last Post: Niek

Forum Jump:


Browsing: 1 Guest(s)