- I came to a conclusion regarding how to watch for new connections.
- I discovered a correction for a previous correction.
- I analyzed ways of calling ejabberd_http_bind.
Looking at mod_http_bind:process, I have to wonder if things are as bad as they look. The answer is: if you have to ask the answer is probably yes.
process([], #request{method = 'POST',
data = []}) ->
?DEBUG("Bad Request: no data", []),
{400, ?HEADER, {xmlelement, "h1", [],
[{xmlcdata, "400 Bad Request"}]}};
process([], #request{method = 'POST',
data = Data,
ip = IP}) ->
?DEBUG("Incoming data: ~s", [Data]),
ejabberd_http_bind:process_request(Data, IP);
process([], #request{method = 'GET',
data = []}) ->
{200, ?HEADER, get_human_html_xmlel()};
process([], #request{method = 'OPTIONS',
data = []}) ->
{200, ?OPTIONS_HEADER, []};
process(_Path, _Request) ->
?DEBUG("Bad Request: ~p", [_Request]),
{400, ?HEADER, {xmlelement, "h1", [],
[{xmlcdata, "400 Bad Request"}]}}.
If I want to use this approach to starting up http_bind, I will need to create a request object. The good news is that it doesn't appear that the function actually looks at anything other than the method, data, and ip fields. This is based on the lines
process([], #request{method = 'POST',
data = Data,
ip = IP}) ->
?DEBUG("Incoming data: ~s", [Data]),
ejabberd_http_bind:process_request(Data, IP);
The bad news is that the data is expected to be a list a la the results of erlang:decode_packet.
One thing that this option makes plain to me is that, if I'm going to have to parse the data into HTTP headers anyways, why not call ejabberd_http_bind:process_request directly, instead of calling it through mod_http_bind? It ends up going to the same place, and if I call it directly, then I don't have to deal with creating a request object.
hmm....
Next time: starting on the code to parse out the data.
No comments:
Post a Comment