Skip to main content

HTTP_RESPONSE_HEADER and Content-type

10 replies [Last post]
sep
Offline
Joined: 2007-07-05

Hi,
i'm developing a little restful web service that will use Atom Publishing Protocol.
As for some response i need to set a correct Content-type, like "application/atomsvc+xml" for a Service Document for example, i do like this:

Map> m= new HashMap>(1);
ArrayList list= new ArrayList(1);
list.add("application/atomsvc+xml");
m.put("Content-type", list);
mc.put(MessageContext.HTTP_RESPONSE_HEADERS,m);

where mc is the MessageContext, of course.
The problem is that when i look at the response packet the server send, it has the Content-type field I set plus another Content-type with "text-xml" value that i'm not able to avoid.
Is there something I'm missing? For the XML part I'm currenty using a String, later converted to a Source object.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
vivekp
Offline
Joined: 2003-06-10

How about the case when it is not DataSource of SOAPMessage? Should the runtime not simply use whatever user is passing - which may result into screwing the request completely, such as in case of MTOM, but then isn't this is one of the case where user is in control and knows what he is doing.

Another approach would be that we define some feature and report error if we see there is any possible conflict during proxy creation?

bhansen
Offline
Joined: 2007-08-15

Hi,

I've tried to implement a custom DataSource, and the runtime doesn't seem to honor the value returned by getContentType() - is this a bug?

Specifically, I return "application/soap+xml" to signal a SOAP 1.2 response.

Is using Provider because this seems to give access to the request as an InputStream. Is there any other way to get access to the request as an InputStream? In JDK 1.6 it was possible to use Provider. However, using 2.1.1 or 2.1.2M1 this now generates an exception during publication.

jitu
Offline
Joined: 2003-06-14

DataSouce is valid only for XML/HTTP binding(not for SOAP binding). For SOAP binding, can you not use Provider and the runtime would automatically send the correct Content-Type.

Regarding Provider, you should use Provider since runtime can give any type of Source. But you could return StreamSource if you want to. For e.g:

[code]
class MyProvider implements Provider {

public Source invoke(Source s) {
return new StreamSource(...)
}
}
[/code]

vivekp
Offline
Joined: 2003-06-10

You mean there are duplicate Content-Type HTTP header? Can you provide the message trace(HTTP headers as seen on the wire)?

-vivek.

sep
Offline
Joined: 2007-07-05

yes, exactly...that's what i find with tcpdump:

HTTP/1.1.200.OK..
Transfer-encoding:.chunked..
Content-type:.application/atomsvc+xml..
Content-type:.text/xml

vivekp
Offline
Joined: 2003-06-10

This looks like a bug, please report an issue on this.

-vivek.

jitu
Offline
Joined: 2003-06-14

Usually Content-Type and Content-Length headers from HTTP_RESPONSE_HEADERS interfere with runtime. I suggest using Provider using XML/HTTP binding. Then runtime will use Content-Type from DataSource.

kohsuke
Offline
Joined: 2003-06-09

What's the harm in honoring the user-specified Content-Type?

jitu
Offline
Joined: 2003-06-14

In some cases, we could honor user-specified Content-Type. In some cases, the runtime may create/add attachments, and update boundary string in the Content-Type. Also, there are two places where Content-Type could come from:1) DataSource or SOAPMessage 2) HTTP_RESPONSE_HEADERS. If both are there, then runtime doesn't know which to honor.

kohsuke
Offline
Joined: 2003-06-09

Ah, that's right. I see that this is tricky wrt MTOM, FastInfoset, etc.