Just came across a person telling one of my colleagues to use jetty with his project and expose a JSON. Just curious about what it means. I searched the internet but found nothing. So what does it mean to expose a JSON?
As far as I understand, jetty is simply just another http server just like Tomcat etc. How is jetty different and how would it be used to expose a JSON?
Jetty is just a server like Apache's Tomcat or any other.
Since nobody has posted an answer on this, Exposing a JSON merely means receiving the response from a certain webpage (using the getmethod) in the form of a JSON. This could also be XML for people who would prefer that.
Browsers like Chrome and Firefox provide plugins that can be used for the same.
For Chrome, one such plugin is Postman. Can be added to your browser simply by going to the Chrome Web Store and searching for the same.
Hope this helps!
Related
On an intranet site, let's say I want to link to a file on a share using UNC, at:
\\servername\foldername\filename.rtf
It seems the correct way to do this is with markup like this:
filename.rtf
That's five slashes - two for the protocol, one to indicate the root of the file system, then two more to indicate the start of the server name.
This works fine in IE7, but in Firefox 3.6 it will only work if the html is from a local file. I can't get it to work when the file comes from a web server. The link is "dead" - clicking on it does nothing.
Is there a workaround for this in Firefox? Those two browsers should be all I need to worry about for now.
Since this is obviously a feature of Firefox, not a bug, can someone explain what the benefit is to preventing this type of link?
This question has been asked at least twice before, but I was unable to find those posts before posting my own (sorry):
Open a direct file on the hard drive from firefox (file:///)
Firefox Links to local or network pages do not work
Here is a summary of answers from all three posts:
Use WebDAV — this is the best solution for me, although much more involved than I had anticipated.
Use http:// instead of file:///// — this will serve up a copy of the document that the user cannot edit and save.
Edit user.js on the client as described here — this worked for me in Firefox 3.6.15, but without access to client machines, it's not a solution.
In Firefox, use about:config, change the Security.fileuri.strict_origin_policy setting to false — this doesn't work for me in 3.6.15. Other users on [SO] have also reported that it doesn't work.
Use the locallinks Firefox extension — this sets the Security.fileuri.strict_origin_policy to true for you, and appears to have no other effect.
Read the file server-side and send it as the response — this presents the same problem as simply configuring your web server to use http://.
Browsers like Firefox refuse to open the file:// link when the parent HTML page itself is served using a different protocol like http://.
Your best bet is to configure your webserver to provide the network mapped file as a web resource so that it can be accessed by http:// from the same server instead of by file://.
Since it's unclear which webserver you're using, I can't go in detail as to how to achieve this.
In Firefox to Open File:\\\\\yourFileServer\docs\doc.txt for example you need to turn on some options in Firefox configuration:
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://yourServer1.companyname.com http://yourServer2.companyname.com");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
As it turns out, I was unaware that Firefox had this limitation/feature. I can sympathize with the feature, as it prevents a user from unwittingly accessing the local file system. Fortunately, there are useful alternatives that can provide a similar user experience while sticking to the HTTP protocol.
One alternative to accessing content via UNC paths is to publish your content using the WebDAV protocol. Some content managements systems, such as MS SharePoint, use WebDAV to provide access to documents and pages. As far as the end-user experience is concerned, it looks and feels just like accessing network files with a UNC path; however, all file interactions are performed over HTTP.
It might require a modest change in your file access philosophy, so I suggest you read about the WebDAV protocol, configuration, and permission management as it relates to your specific server technology.
Here are a few links that may be helpful if you are interested in learning more about configuring and using WebDAV on a few leading HTTP servers:
Apache Module mod_dav
IIS 7.0 WebDAV Extension
Configuring WebDAV Server in IIS 7, 6, 5
Add your own policy, open configuration "about:config" in the location bar and add three new entries:
capability.policy.policynames MyPolicy
capability.policy.MyPolicy.sites http://localhost
capability.policy.MyPolicy.checkloaduri.enabled allAccess
Replace http://localhost with your website.
Works with Firefox 70.0.
I don't know if this will work, but give it a shot! Old article, but potentially still useful.
http://www.techlifeweb.com/firefox/2006/07/how-to-open-file-links-in-firefox-15.html
I'm currently trying to get a simple client \ server websocket demo up and running and I'm trying to use the C# Nugget project as my server. I can connect to the server through Netscape (v5.1.4) but not through Chrome (v18.0.1) and I've tracked the issue down to the client handshake.
Nugget expects the client handshake to be in the following format which is exactly how Netscape is sending it:
Chrome's client handshake on the other hand is looking like this:
I've highlighted the differences in the two requests that are causing the problem in Nugget server - the sec-websocket parameters.
I'm guessing that Netscape and Chromes implementation of the client handshake are based on different versions of the websocket specification. Has anyone got any more information on this? Is it OK to just add code to handle both types of handshake or is one deprecated?
Any insights welcome,
James
Resources: Understanding Websocket Client Handshakes
It looks like Netscape is speaking the older, deprecated, Hixie variant of the protocol. Safari also uses this. Chrome uses the more modern RFC 6455. You can expect all browsers to use RFC 6455 eventually.
Assuming you want to support as many client types as possible, its okay (indeed correct) to add code to handle both variants. Note that the data framing for post-handshake reads/writes also changes depending on the protocol variant being used.
The user, when he clicks a link, needs to get my compressed html file that his browser will uncompress automatically, without any fuss. What must I do on the server side to accomplish this?
Thanks!
-- ben
I see now from your comment that you're literally trying to get compressed file to open transparently in a browser, not just compress the whole HTTP response.
That is definitely an issue for ServerFault. It relies on two things:
The configuration of your HTTP server (it must be able to determine the appropriate MIME type and tell it to the browser, for most browsers the filename alone is not sufficient).
The browser itself. There's no requirement that browsers be able to transparently open such a file, though many will if given the proper MIME type information.
(Original answer below)
I almost said this belongs on Server Fault, but I think the answer is needed on SO because it's not obvious it belongs on SF unless you understand the mechanisms at work, so:
In most cases, compressing HTTP responses is a capability of web servers, and you or your sysadmin will need to configure the web server (e.g. Apache with mod_deflate) to use that capability.
In the event that your application is its own web server, you need to review RFC 2616 (the HTTP/1.1 spec) and/or the documentation for any framework you're using.
I'm not exactly sure what the right thing is if you're using the webserver like as a reverse proxy... Probably still needs to be in the webserver, if it's possible at all.
What server are you running?
If you have Apache, you can set up mod_deflate
i've got firebug (my team does not have firefox), and the IE developer toolbar(IE7) but I can not seem to figure out how to easily validate if the referenced files in a page are loading (i see javascript errors, but that doesn't succinctly point me to the exact file in a heirarchy of jquery - jqueryUI - datepicker files).
Additionally i'd like to be able to do this remotely, because on our corporate domain some files load fine for me, but not anyone else because they sometimes get encrypted to my domain user. So it would be nice if this process was either simple enough for my teammates to do it very quickly, or ... even better somehow with automation from a remote machine or web service request.
I thought I had seen a simple place on firebug to validate what loaded and what did not, but I can't find it now.
What are my options?
do you tried Javascript Lint?
Or the javascript plugin for Eclipse.
do you know YSlow?
It provides you with a set of excelent tools for web developing and I think it solves your question
I'm trying to use CouchDB with HTML/standalone REST architecture. That is, no other app server other than CouchDB and ajax style javascript calling CouchDB.
It looks like cross scripting is a problem. I was using Cloudkit/Tokyo Cabinet before and it seems like the needed callback function was screwing it up in the URL.
Now I'm trying CouchDB and getting the same problem.
Here are my questions:
1) Are these problems because the REST/JSON store like CouchDB or CloudKit is running on a different port from my web page? They're both run locally and called from "localhost".
2) Should I let CouchDB host my page and serve the HTML?
3) How do I do this? The documentation didnt seem so clear...
Thanks,
Alex
There is a simple answer: store static HTML as attachments to CouchDB documents. That way you can serve the HTML directly from the CouchDB.
There is a command-line tool to help you do this, called CouchApp
The book Mikeal linked to also has a chapter (Managing Design Documents) on how to use CouchApp to do this.
3) you can use CouchDB shows to generate HTML (or any content type)
There are huge advantages to having CouchDB serve/generate your HTML.
For one thing, the pages (which are HTTP resources) are tied to the data or to the queries on the data and CouchDB knows when to update the etag when the page has changed. This means that if you stick nginx in front of CouchDB and say "cache stuff" you get all the free caching you would normally need to build yourself.
I would push for nginx > apache in front of CouchDB because Apache isn't all that great at handling concurrent connections and nginx + erlang (CouchDB) are great at it.
Also, you can write these views in JavaScript which are documented well in the CouchDB book http://books.couchdb.org/relax/ or in Python using my view server http://github.com/mikeal/couchdb-pythonviews which isn't really documented at all yet but I'll be getting to it soon :)
I hope that view servers in other languages start implementing the new features in the view server protocol as well so that anyone can write standalone apps in CouchDB.
I think one way is thorugh mod_proxy in Apache. It forward the request from Apache to Couchdb so may solve the cross scripting issue.
# Configuration file for proxy
ProxyVia ON
ProxyPass /couchdb http://<<couchdb host>>:5984/sampleDB
ProxyPassReverse /couchdb http://<<couchdb host>>:5984/sampleDB
I can't help thinking you need some layer between the presentation layer (HTML) and the model (CouchDB).
That way you can mediate requests, provide additional facilities and functionality. At the moment you seem to be rendering persisted objects direct to the presentation layer, and you'll have no facility to change or extend the behaviour of your system going forward.
Adopting a model-view-controller architecture will insulate your model from the presentation layer and give you some flexibility going forwards.
(I confess I can't advise on your cross-site-scripting issues)