[asterisk-dev] Issues with main/http.c in trunk

[Dan Austin]

Kevin wrote:

>> The code is never reached.  The test for !*c always fails (it exists, but
>> might not contain anything interesting).  I replace that with !strlen(c),
>> which then allowed the code to get as far as the test for supports_*
>> which also tended to fail.

> That's not making any sense to me; the first version is checking to see
> if the character pointed to by 'c' is zero, and the second is > checking
> to see if the string pointed to by 'c' is zero-length. By definition
> those are the same thing.

Oh, I agree.  I only tried that after adding a stack of ast_verb
calls to track variables and never once passed the !*c test

>> My patch for this is growing, which lowers my confidence.  I found I needed
>> to add the support_get or support_post to all callbacks, otherwise I would
>> be able to load the page or submit forms/commands, but not both.

> Yes, all callbacks now need to specify whether they support GET, POST or
> both. I made these changes in manager.c when I committed the changes to
> http.c. What 'all callbacks' are you referring to?

> In addition, http.c generates a warning message when a callback is
> registered that does not specify at least one of GET or POST; did you
> not see those messages?

All callbacks had at least one method.  As I said, I am out
of my element in the http code.  I was finding a mismatch between
that the browser sent/requested and the expected methods.
A URI with no variables always seemed to be a GET and if variables
were included on the URI, it seemed to always be a POST.

So interactive URIs (manager and I guess rawman/mxml) needed to
support both methods.




>>  And I am not sure it is related, but I cannot use the ajamdemo as the browser
>>  complains about astmanEngine not being define, which points to a problem
>>  delivering the *.js includes.
>
>> I can put the patch up on Mantis tomorrow.  I fully expect it to not
>> be the solution, but maybe it can better explain the issues.

> I'll look for that, but I'm concerned that you are seeing behavior that
> doesn't seem to make any sense :-)


Does the http interface work for you with a recent checkout of
Trunk?

Dan