What is the best available method for developing a spell check engine (for example, with aspell_python), that works with apache mod_python?
apache 2.0.59+RHEL4+mod_python+aspell_python seems to crash.
Is there any alternative to using aspell_python?
Looks like RHEL4 is the culprit. Works well on Fedore 7 (the version of apache is newer and there is no crash)
Related
I'm setting up Apache on Centos the way I have done in the past, but for some reason mod_spdy is not running. I'm following the instructions here:
https://developers.google.com/speed/spdy/mod_spdy/
When I run rpm -U mod-spdy-beta_current_x86_64.rpm I get this message:
warning: mod-spdy-beta_current_x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 7fac5991: NOKEY
package mod-spdy-beta-0.9.4.3-420.x86_64 is already installed
If I open chrome://net-internals/#spdy and my site in another tab, it doesn't show my site. If I look in the network panel, I don't see the x-mod-spdy header.
Update: If I use Firefox firebug, I see the x-mod-spdy header. I don't see my site in Chrome spdy sessions, but I see other sites in it.
What could I be doing wrong?
Ok it seems the issue is that Chrome 40.x dropped support for SPDY/3 and only supports SPDY/3.1, but the mod_spdy module for Apache only supports SPDY/3, so basically no SPDY for Chrome users if you use Apache as a web server.
mod_spdy is currently in a bad state where either Google nor Apache is maintaining it after Google donated it to the Asf. Google recently made the statement that they will drop the SPDY support from Chrome in early 2016, but what they forgot to say that they started dropping older versions of SPDY already (including SPDY/3) (I like these partially true statements by the way), so basically if you are on Apache then for your Chrome users you can't provide SPDY short of implementing SPDY/3.1 yourself.
So, how was that "do no evil"? :-)
See details: https://groups.google.com/forum/#!topic/mod-spdy-discuss/FPEj0zG5I0Y
and https://code.google.com/p/mod-spdy/issues/detail?id=100&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20Stars
One option you might consider is switching to Nginx and using SPDY/3.1 over there.
I'm working on a project and what I want to do, I have installed lighttpd on my raspberry pi which is running xbian and I have created asp file using to control xbmc by using some .net library.I got mono application as well to control xbmc and I want to send command or signal or message from lighttpd to the running mono application
How to do this, do i have to use any rpc, pipe etc.
thank you
You could either use the lua or php plugin, parse the requests there and run your stuff accordingly.
A rather difficult alternative would be to write a plugin yourself and make that do whatever it needs to do (though this will require at least decent C skills as well as security awareness) http://redmine.lighttpd.net/projects/1/wiki/HowToWriteALighttpdPlugin
https://www.mono-project.com/docs/web/fastcgi/
Separately, if files are downloading instead of being processed, then ensure that you have configured lighttpd.conf mimetype.assign
Hi as the title says I'm looking for a cross platform reverse proxy that can be pre configured and then redistributed.
Reason
There are multiple people running 5 apps on servers
locahost:8080
locahost:8081
locahost:8082
locahost:8083
locahost:8084
Now with the reverse proxy I would like to set it up so
localhost/one
localhost/two
localhost/three
localhost/four
localhost/five
I could manually set it up with Apache or something similar for each person but it seems wiser to pre configure something and then just redistribute it so everyone can just run it and it works out the box. I was thinking of python as its cross platform but haven't found anything suitable yet. Does anyone know of anything that doesn't have tons of frills and is lightweight?
Thanks
I know this is rather late, but Node.js has a number of proxy components that would fit. node-http-proxy being the most commonly quoted.
Node.js works well on multiple platforms (Windows, Mac, Linux at least) and is based on Google's "V8" JavaScript engine. It is non-blocking and highly performant.
I can't seem to get Orbited working with my Twisted app. I have a page, served by Twisted (say localhost:8000/page) which includes Orbited.js from the orbited server (localhost:8001/static/Orbited.js). I then have a TCP chat server example running on port 7777. I try to use Orbited.TCPSocket to connect to the chat server:
conn=new Orbited.TCPSocket();
conn.open("localhost", 7777);
conn.send("test\r\n"); //error: bad readyState
It works fine when Orbited is serving the page, but not when twisted serves it from a different port. My orbited.cfg looks like this:
[listen]
http://:8001
[access]
* -> localhost:7777
And before (which worked) I had this in it as well:
[static]
test=index.html
Where index.html was another page grabbing localhost:8001/static/Orbited.js, and was accessed from localhost:8001/test.
How do I need to change my config file to work with requests from my twisted site on another port?
Update
I tried changing Orbited.settings.port to 8001 before trying to open the connection, but I got an error: "unsafe javascript attempt to access frame with url http://localhost:8000/page from frame with url http://localhost:8001/static/xsdrBridge.html#1. Domains, protocols and ports must match."
Hmm, also, I just looked at the orbited wiki, and apparently, setting Orbited.settings.port is exactly what I'm supposed to do. but I'm getting horrible errors
You can call send() only after the connection is in opened state.
Put a handler for .onopen() and do a .send() from there.
I have used Orbited in the past. It works in general but there are several quirks to get it set up and running smoothly. The project itself seems to be in a state of flux (it seems to be moving to node.js). Both of these points lead me to suggest that - if you can avoid it - not to use Orbited.
Are there alternatives that are cleaner? I would say, yes. You can pretty much emulate Orbited with Websockets on stock Twisted. This will clearly work for newer browsers. What about older ones? Well, there are open-source projects that wrap websockets and fall back to flash as a transport for older browsers. The setup works quite well, and actually feels cleaner than using a solution like orbited.
If you check out http://github.com/rlotun/txWebSocket you'll find the current state of Twisted's websocket implementation, as well as an example of how to fall back to flash on older browsers. Hopefully this will be useful enough for you to serve as a drop in replacement to Orbited.
Just ported a webapp from TurboGears to Django and going through the process of getting a proper server running (i.e. not runserver). Tried going the recommended Apache + mod_wsgi route that the Django docs talk about, but for some reason the thread stalls out with no error message or anything as soon as you try to import CoreData anywhere in a module that Apache is loading.
Specifically, the point at which it stalls out is in the CoreData/__init__.py file here:
__bundle__ = _objc.initFrameworkWrapper("CoreData",
frameworkIdentifier="com.apple.CoreData",
frameworkPath=_objc.pathForFramework(
"/System/Library/Frameworks/CoreData.framework"),
globals=globals())
Not sure what it is about CoreData that makes this fail, since import Foundation works fine (i.e. it doesn't seem to be that all the PyObjC stuff is broken under Apache, just CoreData).
I'm kinda looking into going the lighttpd route now instead, but if anyone could shed light on how to make the mod_wsgi way work that would be good, as I would prefer to stick as close to the suggested simplest deployment method as possible.
Thanks in advance for any insights.
Also: I'm on OSX 10.6.4 with whatever latest version of PyObjC & Apache comes with that, plus the latest mod_wsgi I grabbed from the Google Code website.
Try forcing WSGI application to run in main interpreter. Sounds like PyObjC is not implemented correctly so as to be used in sub interpreters. See:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API