Whenever there is a doGet or a doPost overridden the sockets don't work properly.
One can get it to work by removing both the above functions.
Problem : I am giving support on IE9. So as a back up mechanism I am going back to polling which makes a POST or GET request. Now as the same WebSocketServlet doesnt have a doGet and doPost, I am not sure what to do. HELP ?
Does Jetty WebSockets have the same problem ?
I think it is sufficient to call super.doGet(req, resp) from your own doGet, as this is the method that takes care of setting up the websocket (check the source code of org.apache.catalina.websocket.WebSocketServlet).
This worked out just fine for my case, I'm using tomcat-7.0.42.
Well,
Why not just create two separate Servlets? It doesn't make much sense to mix the code, if you have two separate components, you can still call the WebSocketServlet for normal cases, and if you detect IE9, call the other servlet that supports your polling mechanism.
Regards
Related
I am using Spring Security with Spring Controllers. There are some weird requests caused by some third party browser extension ending such as undefined or weird hexadecimal numbers. I would like to configure my application to block these requests but I could not find an easy way.
I do not want to declare a empty controller for this purpose. What is the correct way to return no-content for these requests?
Edit:
Some sample requets:
/activity/favorites/undefined
/activity/favorites/my/undefined
/help/undefined
Create some servlet filter that is invoked for every request (*). That filter has to check the request URL, and if it is on of the "strangers" that return what you want, but prevent the request from being future processed.
I am currently experimenting with IBM JAX-RS capability through WAS 7 and Web 2.0 Feature Pack 1.1.0.0. The problem I am running into is the client Dojo ajax call poses CORS situation and I am basically trying to figure out how I could properly handle the OPTIONS request.
I followed the example in the referenced url (although it's for WAS 8, it should not affect the part I am playing with); however, it is reported that the system cannot find any method that supports OPTIONS.
Any help will be appreciated!
Reference URL: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-base-iseries&topic=twbs_jaxrs_wadl_serving
Although it's less than a day, since I did not see any response, I want to post out the temp solution I pieced so far.
First of all, check out below link from Mozilla for a better understanding of CORS and OPTIONS request (it did the trick for me).
Link: https://developer.mozilla.org/en-US/docs/HTTP_access_control
Next, one update on the problem of IBM JAX-RS handling OPTIONS. It appears OPTIONS request is handled no different than other GET/POST, it requires an exact match of #Path value. This is not really desired, and in my case, I tried wild card in #Path value, that did not do the trick of triggering the system to handle OPTIONS.
Now, for the solution. With no surprise, I end up using a filter to forward the OPTIONS request to a method inside the resource annotated with #OPTIONS and fixed #Path value, e.g. #Path("options").
In filter, I am handling Allow-Origin and Allow-Header, then I left the resource's #OPTION method to deal with Allow-Methods.
It is very simple and basic solution. Along with proper checking inside filter, the header does not need to be added excessively for every request.
One catch here, it works for Chrome (Version 23.0.1271.95 m) and Mozilla (9.0.1), but not IE. I am still trying to figure out how IE is responding to these CORS. Hope this helps.
On Wednesday the AJAXy CRM system I maintain broke for many users, because Firefox started reporting "Use of XMLHttpRequest's timeout attribute is not supported in the synchronous mode in window context" . The other major browsers still work fine so as a workaround I have advised people not to use Firefox.
From what I understand synchronous requests are A Bad Thing, so I can only assume some recent update to Firefox has stopped it from accommodating Bad Things. All previous discussions (here and on the web) imply the use of the timeout attribute with synchronous XMLHttpRequest objects shouldn't work at all, which leads me to wonder why it apparently does (except on Firefox as of Wednesday).
Are the other browsers / old Firefox actually implementing timeout behaviour where they "shouldn't", or do they just ignore the exception and continue execution (rather than bailing out like new Firefox)?
EDIT: I can't get to the code right now but it was along the lines of:
if (c.somekindoftimeouthandler !== "unassigned" && this.timeout) {
c.timeout = this.timeout
//more stuff about the handler etc...
}
where 'this' is come complicated thing presumably inherited from XMLHTTPRequest and 'c' is a specific object referring to the specific AJAX request, or something. I'll come clean that I know little about both Javascript and this specific Sugar-based CRM, but the essence of the code was simple. It was a generic object-oriented way to make requests, and this particular 4-lines or so dealt with when the request timed out. I get the impression this was an abstract base from which specific requests (or requesting entities) were supposed to specialise. The Firefox Javascript engine chokes on the this.timeout.
I believe the thrust of my question is more general though - given the 'badness' of using timeout for synch XHR, how do the various browsers deal with it?
IE allows 'timeout' to work for sync XHR. If the timeout time is reached, it'll throw an exception from send(), I believe.
Firefox implemented exactly what the XHR spec says: timeout is supported on async XHR but not supported for sync XHR (throws if you try to set it).
Other browsers (and old Firefox) don't support timeout at all; they don't even have the property. Since your script is sniffing for whether the property is there, it doesn't even try to set timeout in those other browsers, which is why it works there: your script is not trying to do bad things, so those browsers don't end up throwing an exception.
So all that changed is that Firefox added support for the timeout property, but instead of doing what IE does it implemented what the spec says to do. And your script was assuming that any browser that implements the property will behavior the way IE does...
I'm creating an external service of my rails app. This is always listening a rabbitmq queue and all their messages should be redirected to some methods of the rails controllers.
I've tried these approaches:
AMQP subscriber inside Rails app
What's the correct way to run one controller action from another controller action without an HTTP redirect?
http://www.misuse.org/science/2007/07/24/firing-rails-controller-actions-from-command-line-console/
The first one allowed me only to access the model (Anyway I suppose must be the base for what I want). The second one... never worked for me. And the last one doesn't works on rails 3 ( ActionController::Integration doesn't exists)
I think that the last approach still could be used if I figure out how the sessions are handled in rails 3. In any case, somebody had tried something similar before? Any suggestion will be appreciated.
Why not just send the request via an HTTP request? Your controller basically makes actions visible via URLs - simply making a request to the URL is essentially the same as calling the controller code, and it keeps your code working like a software service/API. You could even just use curl to do this if you want.
Otherwise, if the two files are in the same machine/folder, you could try to explicitly include the one controller code in the other, but that seems like maybe not the way to go. Depends on how you want the end result to work.
I'm attempting to port over an Internet Explorer plugin to Firefox, but I'm not sure where to look for what I need.
Basically I need to be able to filter all content that is received by the browser with a certain Content-Type header. I tried implementing a stream converter, and this works, but only for the top-level document in the page, frame, or iframe. I had the same problem with IE, and getting around it was really hacky, and since I would ideally like this to be cross platform I would really like to be able to do this in Firefox without resorting to vtable hacks.
The content is served compressed with a proprietary compression format. So I need to receive the data, decompress it, and change the Content-Type back to what the original uncompressed file should have.
If there is a way to just filter all data received, that would probably be acceptable, I could handle parsing the header myself.
Thanks
I think I may have found what I needed. I came across this link which is used for tracing HTTP calls: http://blues.ath.cx/firekeeper/resources/http_tracer.html
There seems to be some problems with the JavaScript implementation for some reason, and I'm not a JavaScript guru to figure it out, but I've implemented it in C++ and initial results suggest that I should be able to modify it for my needs.
Basically we're replacing the nsIHttpProtocolHandler service with our own implementation, which keeps a reference to the initial implementation. When a call is made to the service, we just proxy it over to the saved original implementation. Then we provide our own implementation of nsIHttpChannel and nsIStreamListener which we use as proxies too.
Again we proxy most of the calls back off to the original handlers. But in OnDataAvailable, instead of passing the data on to the underlying nsIStreamListener, we save it using nsIStorageStream. Then in OnStopRequest, after we've gotten all of the data, we can decompress it and then call OnDataAvailable on the original handler, followed by OnStopRequest.
It has worked on some small simple tests so far, but I'll have to put it through some more rigorous tests... I'll also have to figure out if I can do the same thing with HTTPS.
The biggest problem I see at the moment is that it relies on some unfrozen interfaces such as nsIHttpChannelInternal. Can't be helped though as far as I can tell, and my version compatibility requirements are pretty small, so I can live with it if I have to.
In the meantime, if anybody has any other suggestions, I'm all ears :D