The Prosody server has several modules that allow it to respond to HTTP requests.
For example, mod_http_rest allows me to make a POST request on port 5280 with an XMPP stanza as the payload, and the Prosody server responds by sending that stanza on its way.
However, I am looking for a module that would do the opposite: i.e. take an XMPP message received by the usual means, and make an HTTP POST request to a specified server with that message as the payload.
I can't seem to find any module that will do this. Is there such a thing?
If not, is there any functionality available in the Prosody API that would allow such a module to be written?
Alternatively, are there good reasons why this might be a bad idea?
To answer your question, yes, it's possible for Prosody to make HTTP requests to external services.
The module you describe (take XMPP and forward it over HTTP) did not exist, but there's little reason for it not to. So I just published a module that provides this feature: https://modules.prosody.im/mod_component_http.html
I dont known if there is a module already for that but there is a way to achieve it yourself. I made my own module some months back for specific purposes and I used net.http which as the Docs say:
Is an API for making non-blocking HTTP requests to remote servers.
So you should check the Docs from here so you can use it like:
local req = require "net.http"
req.request( URL, opts, callBack )
Where opts are your options in json, and callBack is a function that defines what you want to do with the response.
I hope it helps.
Related
As we all aware the HTTP method has certain properties like, idempotent, safe and cache-able and its defined through HTTP specification by W3C.
My question is who is responsible to implement these HTTP properties. Is browser client, or the server, or both the browser and server which implement the properties of HTTP.
The client asks for something. The server responds with something.
For it to be idempotent, you should expect to get the same response if you ask for the same thing. Only the server can decide what is in the response, so that has to be implemented by the server.
For it to be safe, the request must not alter the server. Only the server can decide to alter something or not based on the request.
Caching takes place on the client (it decides if it should make a request or not based on what data it already has). Only the client can make that decision. (Of course, the server is responsible for giving the client the information they need to make that decision).
in flask-socketio, is it possible to force the transport to be only web socket?
According to the original protocol:
https://github.com/socketio/engine.io
transports (<Array> String): transports to allow connections to (['polling', 'websocket'])
My goal would be to get rid of the original HTTP call.
Best,
See this post - Socket.io 1.x: use WebSockets only?
It looks like you can't get rid of the original HTTP call, but you can tell the client not to use long-polling.
var socket = io({transports: ['websocket']});
I can't find a way to disable it from the server-side with Flask-SocketIO.
According to the documentation of Flask-SoskcetIO you can use async_mode to set async_mode. if you installed eventlet or gevent with gevent-websocket the websocket would be used first.
async_mode: The asynchronous model to use. See the Deployment
section in the documentation for a description of the
available options. Valid async modes are
``threading``, ``eventlet``, ``gevent`` and
``gevent_uwsgi``. If this argument is not given,
``eventlet`` is tried first, then ``gevent_uwsgi``,
then ``gevent``, and finally ``threading``. The
first async mode that has all its dependencies installed
is then one that is chosen.
I have recently implemented a CORS IDispatchMessageInspector applied through a BehaviorExtensionElement for services within a large project I am working on to allow for CORS support (arising from calling REST WCF web services from jQuery Ajax calls).
The current implementation intercepts all OPTIONS method calls to an endpoint with the CORS behavior specified and responds with the appropriate headers (and a 200). As it stands the service will expect to see OPTIONS requests only in the case of CORS requests, however I cannot guarantee that this will always be the case.
In the interests of future proofing and extensibility, what are the most common reasons for OPTIONS requests outside of CORS? Are there plans to extend the use of such requests in future WC3 specs (as this seems to suggest)? Are there any use cases that I should attempt to allow for?
It's the other way around.
A CORS preflight request will be an OPTIONS request including an Origin and Access-Control-Request-Method request header, by which you can recognize it as such.
Any other OPTIONS request is just that, and can be sent by any client for any reason.
WebDAV clients are known to use OPTIONS to probe for support for protocol levels and method support (see RFC 4918).
In how many ways can an HTTP request be generated?
There are endless ways how you can create and from where you can send HTTP requests to a server. Actually your server has no idea, what the origin of such a request is (if it's AJAX or "regular" request, or sent from a console application or ...)
But there are HTTP methods (HTTP verbs) that (can) tell the server about the intent of the request: http://en.wikipedia.org/wiki/HTTP_Verbs#Request_methods
Also you can set headers in a request, for example the content-type or the accepted encoding: http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
Most JavaScript libraries for example set the (non-standard) HTTP header X-Requested-With, so your application can differentiate between regular and ajax requests.
You see, it's even possible to set your own, non-standard headers. There are endless possible combinations...
HttpRequest is a C# class that wraps a petition sent by a client during a Web request.
There are many ways to generate it. The most usual one happens when your browser connects to an ASP.NET website.
You can, for example, create your own custom HttpRequest to petition a specific web page from a C# console application.
Are you trying to achieve something more specific?
Is it allowable to pass parameters to a web page through the URL (after the question mark) when using the POST method? I know that it works (most of the time, anyways) because my company's webapp does it often, but I don't know if it's actually supported in the standard or if I can rely on this behavior. I'm considering implementing a SOAP request handler that uses a parameter after the question mark to indicate that it is a SOAP request and not a normal HTTP request. The reason for this that the webapp is an IIS extension, so everything is accessed via the same URL (ex: example.com/myisapi.dll?command), so to get the SOAP request to be processed, I need to specify that "command" parameter. There would be one generic command for SOAP, not a specific command for each SOAP action -- those would be specified in the SOAP request itself.
Basically, I'm trying to integrate the Apache Axis2/C library into my webapp by letting the webapp handle the HTTP request and then pass off the incoming SOAP XML to Axis2 for handling if it's a SOAP request. Intuitively, I can't see any reason why this wouldn't work, since the URL you're posting to is just an arbitrary URL, as far as all the various components are concerned... it's the server that gives special meaning to the parts after the question mark.
Thanks for any help/insight you can provide.
Lets start with the simple stuff. HTTP GET request variables come from the URI. The URI is a requested resource, and so any webserver should (and apache does) have the entire URI stored in some variable available to the modules or appserver components running within the webserver.
An http POST which is different from an http GET is a separate logical call to the webserver, but it still defines a URI that should process the post. A good webserver (apache being one) will again make the URI available to whatever module or appserver is running within it, then will additionally make available the variables which were sent in the POST headers.
At the point where your application takes control from apache during a POST you should have access to both the GET and POST variables and be able to do whatever control logic you wish, including replying with a SOAP protocol instead of HTML.
If you are asking whether it is possible to send parameters via both GET and POST in a single HTTP request, then the answer is "YES". This is standard functionality that can be used reliably AFAIK.
One such example is sending authentication credentials in two pieces, one over GET and the other through POST so that any attempt to hijack a session would require hijacking both the GET and POST variables.
So in your case, you can use POST to contain the actual SOAP request but test for whether it is a SOAP request based on the parameter passed in GET (or in other words through the URL).
I believe that no standard actually defines the concept of "HTTP parameters" or "request variables". RFC 1738 defines that an URL may have a "search part", which is the substring after the question mark. HTML specifies in the form submission protocol how a browser processing a FORM element should submit it. In either case, how the server-side processes both the search part and the HTTP body is entirely up to the server - discarding both would be conforming to these two specs (but fairly useless).
In order to determine whether you can post a search part to a specific service, you need to study this service's protocol specification. If the service is practically defined by means of a HTML form, then you cannot use a mix - you can't even use POST if the FORM specifies GET (and vice versa). If you post to a web service, you need to look at the web service's WSDL - which will typically mandate POST; with all data in a SOAP message. Etc.
Specific web frameworks may have the notion of "request variables" - whether they will draw these variables both from a search part and a request body, you need to find out in the product documentation.
I deployed a web application with 3 (a mobile network operator) in the UK. It originally used POST parameters, but the 3 gateway stripped them (and X-headers as well!). So beware...
allowable? sure, it's doable, but i'm leaning towards the spec suggesting dual methods isn't necessarily supposed to happen, or be supported. RFC2616 defines HTTP/1.1, and i would argue suggests only one method per request. if you think about your typical HTTP transaction from the client side, you can see the limitation as well:
$ telnet localhost 80
POST /page.html?id=5 HTTP/1.1
host: localhost
as you can see, you can only use one method (POST/GET, etc...), however due to the nature of how various languages operate, they may pick up the query string, and assign it to the GET variable. ultimately though, this is a POST request, and not a GET.
so basically, yes this functionality exists, is it intended? i would say no.