• 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
no callback on some http requests
#11
So, after your edit. What's the idea?
 
Reply
#12
The idea is that I would still like a user definable time out per request.

I have seen so far that a 3 second time out is too short in many cases. After increasing it to 5 seconds the number of time outs is a lot less, but not zero. Ofc. I can make the time even higher, but for most of the sites and services that wouldn't be necessary. That fact was the reason why I would like a user configurable time out in the http action.

The reason I suggested an optional function parameter was that existing modules using the http library could stay unchanged, unless they also have unwanted time outs.

A config setting that works for all http requests would be a second best solution.
 
Reply
#13
Is this a blocking request or can it wait until i ported the API protocols to Lua? Currently quite far with the actions.
 
Reply
#14
It can wait as far as I'm concerned.

I will do some more experimenting with the timeout value in http.c to find the optimal value for me and I can use that version until then.
 
Reply
#15
Do you feel comfortable releasing a new pilight version with the last fixes and additions?
 
Reply
#16
Yes, with the latest fixes I think it is good for a new release.
 
Reply
#17
@curlymo,

I have an issue when I call the weather underground api (my api key hidden).

Code:
http://api.wunderground.com/api/xxxxxxxxxxxxxxxxx/conditions/hourly/alerts/q/nl/haarlem.json

The issiue is that although weather underground is responding within a second, a callback with 408 code occurs. In fact the callback occurs  immediatly after the request is being sent.

Now you may rember that you made a fix in the http library for requests where no callback was done in this commit.

That fix indeed fixed the issue where some requests never resulted in a callback, but it appears to have a side effect that causes the issue described above.

I changed this piece of code:

Code:
        if(request->has_length == 0 && request->has_chunked == 0) {
            if(request->callback != NULL && request->called == 0) {
                request->called = 1;
                request->callback(request->status_code, request->content, strlen(request->content), request->mimetype, request->userdata);
            }
        } else {
        /*
         * Callback when we were receiving data
         * that was disrupted early.
         */
            if(request->callback != NULL && request->called == 0) {
                request->called = 1;
                request->callback(408, NULL, 0, NULL, request->userdata);
            }
        }


To

Code:
        if(request->has_length == 0) {
            if(request->callback != NULL && request->called == 0) {
                request->called = 1;
                request->callback(request->status_code, request->content, strlen(request->content), request->mimetype, request->userdata);
            }
        } else {
        /*
         * Callback when we were receiving data
         * that was disrupted early.
         */
            if(request->callback != NULL && request->called == 0) {
                if(request->has_chunked == 1) {
                    request->called = 1;
                    request->callback(408, NULL, 0, NULL, request->userdata);
                }
            }
        }

So in fact I removed the check for request->has_chunked from the condition for the normal callback and added a condition with that check for the 408 callback.

That fixes the issue, and until now I haven't seen any side effects. However please have look at that commit to see if my solution is the right one.
 
Reply
#18
Make a PR against the rewrite branch and we'll see if all test still succeed.
 
Reply
#19
I've tested your fix and it doesn't work.

Can you post the weather underground communication (e.g. headers being sent and received).
 
Reply
#20
The issue should be fixed.
 
Reply
  


Possibly Related Threads...
Thread Author Replies Views Last Post
  ][solved]Segfault when retrieving big chunked http message Niek 21 5,591 11-29-2018, 03:17 PM
Last Post: curlymo
  http code 301 causes segfault Niek 3 3,276 08-14-2018, 06:57 PM
Last Post: curlymo
  http library doesn't properly handle big response Niek 39 6,365 07-17-2018, 07:26 PM
Last Post: curlymo
  [Solved] callback not executing when dns lookup fails Niek 1 606 10-08-2017, 11:44 AM
Last Post: curlymo

Forum Jump:


Browsing: 1 Guest(s)