I was looking around for a way but I've only got that Nginx does implement the normal SNI and that's it.
Can it be that ESNI is still a "not yet ready" feature for Nginx?
Since ESNI (or ECH, as it's now called) is not supported by OpenSSL, it can't be supported by nginx, either.
Related
Is it possible to have RabbitMQ Consumer listening to a queue for message via AMQP protocol. I am aware that nginx only supports HTTP/s protocol. Was wondering if this can be achieved by using tcp module extension.
I am using nginx as API Gateway and want to do a protocol translation from AMQP to HTTP since all the backend service's are exposed on HTTP.
It would definitely be possible writing your own C extension. nginx is suitable for TCP proxying, therefore I don't see any reason why you couldn't send your own TCP packets to RabbitMQ using nginx, and consequently use nginx as a RabbitMQ consumer. It's probably a lot of work to make it run, and even more work to make it stable and reliable, but doable. Do me a favor though, don't do this. There will always be better, more elegant and simpler solution.
HTTP is definitely not suitable for consuming from a queue (in the amqp sense) because you have to keep the socket open while you consume. However, you could write a C extension to publish/retrieve messages to/from RabbitMQ (and apparently, somebody has already done this). If you're not that much into C or don't want to maintain your own nginx package, you could also write a LUA extension for lua-nginx-module (once again, somebody seems to have worked in this direction). These are PoC for talking to MQ from nginx, but they are not consumers. Both extensions seems to act in the HTTP context, so you need to answer (and close the socket) pretty fast.
However, as far as I know, there isn't any community-driven and well maintained project that would serve this purpose directly or indirectly; you'd have to make and maintain your own extension/client. Moreover, nginx is your current API gateway. Do take the risk into account. Things could go really wrong. Only you can tell whether it is worth the hassle or not, but it's most likely not.
Since you don't gave that much information on what you're exactly looking for, I just answered you on the NGINX/AMQP part. But you might just be looking for an HTTP interface for RabbitMQ. In this case, the Management Plugin might be the way to go. It has a pretty cool HTTP API. Once again, you'd loose every stateful features (like basic consuming, ack/nack/rejects), but that's inherently due to the way HTTP is designed.
Eventually, if you really need a RabbitMQ "basic-"consumer, I would recommend you to write a proper consumer as a separate application and forget about doing this in nginx. That's definitely the best and most supported solution.
I ve come to http2demo.io today and I already have some good experience with SPDY .. so, do you plan/adise using HTTP/2 cause the results seems valid and quite impressive, and it does not need SSL except of SPDY.
However seems to be Nginx thingy, is it a trouble?
Looking for possibilities / alternatives for backend HA in nginx. At the moment we are using lua-nginx which does not support HttpUpstream module, which would be first choice for me. I know a bit about pacemaker but not never used it so not sure if it would be good combination with nginx. Any hints, experience?
I'd like to set up a reverse proxy for my webdav server. The main reason for this is so that I can better control which files are being uploaded to the webdav server. I cannot do this at the webdav server itself, it's a service by alfresco and I have now idea whether or not it's possible to configure the webdav service at all.
In particular I'd like to prevent my mac to do the AppleDouble thingy on the webdav server, i.e. stop my mac from uploading ._* files for every real file I upload. There is as far as I know no way to stop my mac from attempting this.
Does the proxy server need to know more than merely relaying http requests back and forth, does it also need to know something about webdav in order for this to work?
Which proxy servers could your recommend for this?
Günther
Unless I'm missing something, a reverse proxy will have to rewrite header fields (such as Destination: and If:) to work properly and potentially even request/response bodies, and thus is unlikely to work well.
A "proper" proxy shouldn't get in the way, though.
You could do this with SabreDAV. It has a TemporaryFileFilter Plugin that does exactly what you need. Not only does it intercept these resource forks, it also places them in a temporary 'quarantine'. This is important, because OS/X will check if the file was successfully written and fail horribly otherwise.
There will be two things you still need to do to make this work though:
Automatic cleanup of these files (a script suitable for cron is also supplied).
The actual proxy bit. This means you'll have to implement a Collection and a File class that perform the HTTP requests.
Disclaimer: I authored SabreDAV
I have been studying the Upgrade header field in HTTP 1.1 (RFC 2817) and happened to read the wikipedia entry for HTTP. That article has the following statement:
"Browser support for the Upgrade header is, however, nearly non-existent, so HTTPS is still the dominant method of establishing a secure HTTP connection."
I was hoping to implement my web service so that it relied on the Upgrade header field in order to avoid having to listen on two sockets (one for HTTP and the other for HTTPS). This statement, which I have not been able to verify any other place, makes me somewhat nervous about doing so. Is the above statement in wikipedia anywhere near correct or is it a gross generalisation?
I was researching this for that Wikipedia page actually and came across this question. I've looked around and here's the browser support situation as near as I can tell:
Chromium supports the Upgrade header as indicated by, for instance, this bug.
Firefox does not support "Upgrade: TLS" despite an open bug from 2005, last comment from 2010. My guess is they won't be adding it anytime soon.
Internet Explorer 10+ probably does, given this article that describes using Upgrade to connect to a websocket server. This commit message also implies IE 10 supports "Upgrade: websocket".
Safari 6+ supports Upgrade (see here).
For all of the supported browsers, I only found examples of "Upgrade: websocket" usage, none saying that upgrades to TLS would work. So the overall answer is that it's risky to rely on this in a production application.
Server support seems better; Apache has had "Upgrade: TLS" support since 2.1.
I would rather like to have it all in http, but the current situation leans more to Server Name Indication, as its widely supported. Its also hard to indicate that you want the client to upgrade using the url. So, if the goal is virtual hosting, one way to do this is TLS "server name indication". See RFC 3546 http://www.ietf.org/rfc/rfc3546.txt or http://en.wikipedia.org/wiki/Server_Name_Indication