As far as I understand this isn't supported in OkHttp 2.0. I have tried it with no luck so far...
Are there any plans to support this in the near future?
No plans at the moment. Open an issue in the projects issue tracker to start the conversation!
Related
I plan to use Elasticsearch on heroku.
I was looking for the best option of Elasticsearch add-on I can use.
Found was my first choice from the following reasons:
It is now part of elastic.
When using Elasticsearch on heroku it will be opened to the world - a secure wrapper to the transport client was introduced - https://github.com/foundit/elasticsearch-transport-module/
But it looks like this repository is not highly maintained, and Elasticseach 1.5 is the latest version which is supported.
What is the recommended add-on then?
If I want to use the latest version of Elasticsearch I am doomed to use an unsecure connection?
Maybe use the official java client?
Nick with Bonsai here. Based on your question, and my own obvious bias, I'll suggest Bonsai for the following reasons:
All of our clusters have SSL with basic auth to secure the connection. We feel pretty strongly that security comes as a standard feature.
We were the first hosted Elasticsearch provider, ever. (And one of the first addon providers on Heroku, ever, with our first search addon, Websolr.) So we've got plenty of experience hosting search and and thousands of other happy Heroku customers.
One definite tradeoff with using Bonsai is that we're generally always going to lag a bit behind the latest version of ES. As of this posting we're still running ES 1.7, but updates to ES 2.2 are just around the corner.
This is probably going to be true in the future as well. Part of the reason for this is that we're a small, bootstrapped company, and we have to be pragmatic in where we focus our engineering efforts. Plus as an operations company with thousands of businesses, we like to let major new upgrades spend a few months in the wild before we commit to supporting it.
We also work hard on providing managed upgrades, at least for versions that are sufficiently backwards compatible. Everyone has their tools for helping to manage upgrades, but I don't think any of the other providers do actual in-place upgrades.
Unless you have a hard requirement for a specific feature in 2.x (and if you do, please let me know) you may do fine on 1.7 until our 2.x support is fully baked. Drop us a line at info#bonsai.io to get whitelisted for the first release of that in the coming weeks.
does anyone know how to use the new APNS provider API from Apple that was introduced in a Session of the WWDC2015? For my tests I used PushMeBaby(a OpenSource Push server from github). But this little App won't work anymore in the future. has someone implemented a HTTP2 client in Swift yet?
Unfortunately, Apple has still not released any information regarding the new APNS HTTP/2 service, or even anything regarding when information will become available.
Most developers seem to be eager to make the switch to the new endpoints, but we will all have to wait for the time being.
I'm now using this Code from Github.
For me it's actually easier to use the APNSNetwork Class directly, so i don't have to mess up with Carthage.
The Class is very easy to use and available for Swift2 and Swift3.
I hope this will help you in your Project ;-)
Best regards,
Michael
I was asked to establish a connection using the cometD library going from ios7 to a server. After some research I came to the conclusion that my two options were Dave Duncan's DDComet, and Paul Crawford's FayeObjC. I tried using DDComet, but when I opened the github project, it came with 30+ errors. They were mainly ARC errors witch I attempted to fix, but it only ended up crashing the application. I then took a look at the FayeObjC documentation, and quickly realized that it had very little/nothing to do with cometD.
My question is: Is CometD an outdated library? If so, what should I be using as a replacement. If not, how would I be able to implement it in ios7?
CometD is not an outdated library. The last version of CometD is barely one month old.
The CometD project does not have an ObjC client.
I know of companies that have written one and maintain themselves that is fully compatible with CometD 2.x and 3.x.
It may happen that in future their implementation is open sourced.
Faye uses the Bayeux protocol, defined by the CometD project, so in theory they should be able to interoperate. However, I don't know exactly the status of either Faye or FayeObjC.
As the CometD project leader I'd love to have an ObjC client in the project, but it has not happened yet.
How do I specify which port for Play https to start on? In Play 1.2.4 I would add to the application.conf:
https.port=9443
But Play 2.0 does not seem to support this anymore. Also, this syntax plainly does not work:
play start -Dhttps.port=9443
although this way does work for regular http: play start 9100
Anyone know how to do this for https?
According to this answer on the Play! discussion group, direct https support is not available in Play! 2.0 yet:
https://groups.google.com/forum/?fromgroups#!topic/play-framework/I7I7lULd0cI
If you need https, you can either stick with Play! 1.2.4, or put an https-capable web server in front, such as Apache or nginx.
There is a Play 2.0 branch that supports HTTPS.
Official issue status is "in progress", as of time of writing.
If you still want to have HTTPS support in Play 2, it looks like it has been added. I see it is a system property with the name "https.port" as you specified. The change has been in there for a while now. I think what you had tried before should work now under 2.0.3.
Here is where I found that source. It wasn't in the docs.
https://github.com/playframework/Play20/blob/master/framework/src/play/src/main/scala/play/core/server/NettyServer.scala
For what it's worth, it looks like it was added back in by version 2.1.
The latest docs: http://www.playframework.com/documentation/2.3.x/ConfiguringHttps
I'm using new relic to monitor my website and this method is the bottleneck on 80% of my web requests, even on simple GET requests, what does this do?
Dude which version are you using ?
It was a known issue in previous versions.
Upgrade to their latest agent (version 2.0.9.15) - is now available and should fix this issue.