This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Servlets and the fly likes How to set the content type for a GET request from a browser Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "How to set the content type for a GET request from a browser" Watch "How to set the content type for a GET request from a browser" New topic
Author

How to set the content type for a GET request from a browser

Rahul Babbar
Ranch Hand

Joined: Jun 28, 2008
Posts: 210
Hi Ranchers,

Is there a way by which we can set the content type while accessing from a browser?

like when i am accessing, http://localhost:8080/something , i want to set the content type also.

I am able to do it from the java code but still need to see if it can be done from the browser.

Thank you


Rahul Babbar
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

Not sure I understand your question, the content type of the response is defined by the server? What is it you are trying to achieve?

Some browsers (such as IE) will try to perform content type sniffing if none is defined in the response. It's very difficult to tailor this behaviour, you would need to update a whole bunch of stuff in the registry to do it.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12761
    
    5
I think the browser depends on the context to set the request content type options in the Accept headers.

Try the Live HTTP Headers tool with firefox to see exactly what your browser is sending in the request.

Bill
Rahul Babbar
Ranch Hand

Joined: Jun 28, 2008
Posts: 210
Paul Sturrock wrote:Not sure I understand your question, the content type of the response is defined by the server? What is it you are trying to achieve?


Hi Paul,

The requirement is that the clients can ask for the JSON or the XML version of a record or a set of records using a GET request. So i was thinking to set the content-type requested by the GET request so that the servlet can convert the data object into either JSON or XML.
Normally, when from a browser, we do a http://localhost:8080/appName/servletName, its a GET request but no content-type is set.

However the same can be set through a Java client to make a GET request like


and the same can be obtained in the servlet as


So, i was wondering if there was a way to set this property from the browser(but not a request parameters)

Thank you
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

If you want the server to produce one of two formats based on something in the request, the obvious thing to do is to pass a parameter defining the format. This has the advantage that you don't have to do weird things like hacking the browser to make it work, it is just a standard feature of HTML.

William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12761
    
    5
Note: Content-type in a request refers to the type of the data you are sending!

It is the Accept header that gives the type you want.

Here is the Wikipedia convenient page for HTTP headers.

Bill
Rahul Babbar
Ranch Hand

Joined: Jun 28, 2008
Posts: 210
Oh...you are right Bill,

i was confused between the two.

I think i will go ahead with the way suggested by Paul to pass the parameter in the request instead.

Thank you

Rahul
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Or consider using the extension of the request as a response type indicator, like "foo.json" returns JSON, "foo.xml" returns XML, "foo.jsp" returns HTML.
Rahul Babbar
Ranch Hand

Joined: Jun 28, 2008
Posts: 210
Hi David,

I am using Jersey framework for this and eventually i want the requests like foo.json or foo.xml to go to a single method in the Servlet, but i am not sure whether if my urls are different in these cases(foo.json or foo.xml), how will jersey handle the request and how will i read the ".json" part.

Also, i think Jersey provides an annotated way of handling both xml and json in the same method using jaxb but i am not using it because of some other related complexities. so i am using a custom way to convert object to xml or json

Thank you
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12761
    
    5
i want the requests like foo.json or foo.xml to go to a single method


Why in the name of sanity would you want that? It seems to me that the whole idea of jersey is to direct the request to the method designed to return a specific type as set by the annotation.

You are just headed for mass confusion.

See this JAX-RS overview.

Bill
Rahul Babbar
Ranch Hand

Joined: Jun 28, 2008
Posts: 210
i have a large no of methods written for returning the XML type data, and repeating the code for all the methods just because of a different type of data conversion doesn't look good to me.

Because after some other time, a different content type requirement might come, and i dont want to rewrite all the methods just because the content type is different(unless the business logic requires some different processing for different content type)

So, what i am having right now, is that i get my data object from the backend to the jersey servlet and then based on the request parameter convert it to either JSON or XML(and that code is common).

Also, it looks like with Jersey, we can specify 2 or more content types for the same method, and that seems to be ok for what i am trying to do.

Thank you
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How to set the content type for a GET request from a browser
 
Similar Threads
Accessing Japanese characters from text area
SaveAs Dialog problem when downloading file via Servlet.
is setContentType Optional?
downloading file from jsr 168 application
Problem with sending plain text