We have some clients who, upon attempting to submit a form, are recieving the error - "HTTP Status 501 Method OST is not defined in RFC 2068 and is not supported by the Servlet API" being thrown by Apache Tomcat/6.0.29.. Apparently, this error is only being received by users running Firefox on Windows 7.
After a lot of digging, the vast majority of examples of Method = "OST" that I can find are on Chinese language websites.. Like here.. In This discussion (English language) "Quoted Printable Transfer Encoding" was mentioned as the possible cause of a similar problem, but it does not involve Apache Tomcat, or any particular browser/operating system combination.
I have a feeling that this issue is something to do with encoding, but have little experience relating to this.. Has anyone experienced a similar issue, or perhaps have some suggestions as to how I might go about solving it?
Thanks
It may be useful to have a look at the following known and recorded defect in Mozilla Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=723805
This seems relevant to your problem, and it may shed some light on how you could do things a bit differently to avoid it.
Related
I am trying to find a high-level Clojure library for making HTTP and HTTPS requests, parsing out forms and links from responses and then POST-ing updated forms or following links. Ideally something that would automatically handle redirects and cookies (i.e. sessions). That is, I'd like to find something whereby my code can as closely as possible mimic a user driving a webapp from a browser, without the browser.
A number of years ago we used Hpricot and Ruby for a similar task but I'm prefer to do this in Clojure if at all possible. From memory - and I haven't used Hpricot for years - we were able to do all this with minimal effort: we were able to concentrate on the 'what' of driving the application, not the 'how'.
I found clj-http https://github.com/dakrone/clj-http but this seems to be one step lower-level than I'm looking for (no form parsing) - although it is based on Apache HttpComponents http://hc.apache.org/httpcomponents-client-ga/ which does seem to expose a nice, fluent, API for forms http://hc.apache.org/httpcomponents-client-ga/tutorial/html/fluent.html.
Screen scraping in clojure asks about screen-scraping in Clojure, and there are several good suggestions for that, but nothing that really addresses the above.
HTTP Kit http://www.http-kit.org/client.html looks like it would be a great foundation for the above but doesn't do form parsing or session management (as far as I can see).
Currently I've veering toward using the Apache HttpComponents Java library directly from Clojure. Can anyone suggest any better - perhaps more Clojure idiomatic - alternative? Or anything that they found worked well in similar circumstances? My goal is to write the minimal amount of code quickly to investigate a problem with a web service. This is not production code. Saving time, rather than getting an 'ideal' solution is my main concern.
[The background is that I am trying to mimic certain forms of user behaviour in order to first reproduce and then try and track down an intermitent bug in a large body of legacy Java/EJB code. However the problem only seems to occur one time per several thousand POSTs. (The suspicious is of some form of caching issue.) The existence of the problem, after the fact, is easy to detect however.]
Have you looked at the Enlive library yet? Here is a good tutorial on it.
You seem to really have 2 parts here. The first part is (1) a Selenium-like client, which drives (2) a webserver.
For part (1), either Selenium, Enlive, or something similar will allow you to simulate a browser to submit data, read the responses, and respond from there. For part (2), it seems you just need a regular Clojure web framework such as Ring/Compojure (older & simpler) or Pedestal (newer & more powerful).
I am getting the following error when running my metro app:
The runtime has encountered a fatal error. The address of the error
was at 0x6e6b9a68, on thread 0x279c. The error code is 0x80131506.
This error may be a bug in the CLR or in the unsafe or non-verifiable
portions of user code. Common sources of this bug include user
marshaling errors for COM-interop or PInvoke, which may corrupt the
stack.
I have a hard time thinking the CLR is buggy.
The app is pure C#, no C++.
I don't use interop.
What should I be looking at?
If you're building a Metro app, be prepared for this exception to lead to a severe loss of sleep. In the Microsoft forums, there was a thread a while back where we seemed to isolate the problem to occurring when you are binding with custom value converters. Really simple converters are fine but interesting ones will yield this exception at seemingly random times. Good luck.
Every software has bugs. If this problem is reproducible, you should do this: 1) narrow down the problem to a test-case. This will also ensure that the problem is not on your side, and is really in the runtime. 2) search whether there isn't any already posted bug reports or KB articles 3) submit a bug report to Microsoft.
If the crash is reproducible, I am sure Microsoft will try their best to find and fix the bug.
Windows 8 is still in beta. I am not sure "buggy" is a fair adjective for software that hasn't been shipped. To your question - they are probably both buggy at this stage.
Even if your app is pure c#, any call to WinRT API is an interop between c# and c++. The interop layer between them is a responsibility of CLR, and that's why the exception said it could be CLR bug.
I am trying to port an existing, large-scale, multi-platform library to Win8 Metro, but got blocked by some removed APIs. Browsing the documentation and looking into some code samples did not help, I still cannot find a simple, reliable alternative for the missing GetAddrInfoW and getaddrinfo functions. Can anyone tell, what the proposed alternative is for these removed functions? AM I just overlooking something in the docs? Thank You,
György
Are you sure, that those functions really do not exist anymore? The winsock docs specifically mention that GetAddrInfoW was actually extended in Windows 8 Consumer Preview, and not removed.
Quote: "On Windows 8 Consumer Preview and Windows Server 8 Beta, the GetAddrInfoW function provides support for IRI or Internationalized Domain Name (IDN) parsing applied to the name passed in the pNodeName parameter. Winsock performs Punycode/IDN encoding and conversion. This behavior can be disabled using the AI_DISABLE_IDN_ENCODING flag discussed below."
Edit: Looking at it again it says at the top of the document that it only applies to desktop applications. For Metro Apps winsock2 seems to be unavailable and without an equivalent alternative for those two functions. At least i couldn't find one.
I've spent quite a few hours reading up on implementing a specific WSRM policy, the AtMostOnce attribute, to prevent duplication of soap messages. Google brought me to several pages in Red Hat's and Oracle's sites, but it seems all I can really find are one of two things on any page I look at-
A snippet of code showing just the policy brackets, and a bunch of omitted code in between assuming the reader will get the point (I don't :/ ).
A standard example of a WSDL file (defined types, services, ports, bindings, and messages), and then a little bit of text saying what ReliableMessaging is used for, plus the various assertions related to it, and a statement synonmous with "now I'm sure you don't need an example on how to put it all together, so have fun k thnx bye."
All I ask is if someone could please just provide a very simple WSDL example, no code excluded, that implements the AtMostOnce assertion for all messages. Just assume there are only two messages, such as getStuffRequest and getStuffResponse.
Either that or tell me where it is I'm horribly wrong, and perhaps what you consider to be a good resource for learning how to do this correctly.
In the Metro download, there are samples:
samples/ws-rm/javaone-2006-demo
search for RMDemo.wsdl
<wsp:ExactlyOne>
I am new to Blackberry app development. I need to call REST webservice from blackberry application using JDE 4.7. I searched but not got any solution. Anyone help pls?
sri
You have to make an HttpConnection request and read the data as an InputStream... have a look at this tutorial Calling REST based web services
I appreciate this an old post - but it has been updated so someone is looking at it, so I thought it appropriate to contribute.
I am sorry, but I can not recommend the code supplied the link from another answer called "Calling REST based web services".
I have made a comment explaining this on the site, along the following lines:
"In my opinion this code is flawed because it does not consider the different connection methods, nor does it consider different encodings. More over it does not consider the Event Thread or provide reasonable error checking and logging. I appreciate that this is just a sample, but I think the author has a responsibility to make people who might use this code aware of how it should be used properly. And this code will cause more problems that it solves. Refer to the supported BlackBerry documentation and web sites for better samples."
Sorry, I am not as familiar as I should be of the questions asked on stackoverflow, but questions like this come up regularly on the BBRY forum here:
http://supportforums.blackberry.com/t5/Java-Development/bd-p/java_dev
I recommend that you go on that forum and type network in the Search box on that site and you be presented with a range of tutorials and KB articles that discuss all aspects of networking. In this particular case I would recommend this:
http://supportforums.blackberry.com/t5/Java-Development/What-Is-Network-API-alternative-for-legacy-OS/ta-p/614822
Networking is not trivial on the BlackBerry, do not expect a cut and paste of the code supplied to work for you. Specifically you should be aware of:
a) The various connection methods, the costs associated with each and the impact that using each might have (e.g. transcoders or caching)
b) The Event Thread, how to get off it and back on when processing a response
c) Logging and reporting so that you can investigate problems when they occur (and they will).
Personally, given that all OS 4.7 devices can be upgraded to OS 5.0 and should be, since OS 5.0 is better, I would forget supporting OS 4.7. Instead look at OS 5.0 and above support and use ConnectionFactory.