I'm trying to get a project that was made in Mule 3.4 working in Mule 3.7. In Mule 3.4, using the HTTP endpoint-based Connector it was possible to retrieve multiple cookies from response messages by using:
Object cookieObj = message.getInboundProperty("Set-Cookie");
String cookieValSchoolname = CookieHelper.getCookieValueFromCookies (cookieObj, "schoolname");
String cookieValJSessionId = CookieHelper.getCookieValueFromCookies(cookieObj, "JSESSIONID");
In Mule 3.4, using the HTTP endpoint-based Connector, the inbound property "Set-Cookie" contained an array of all the cookies that are set with Set-Cookie in the http header.
However when I use the same code with the new HTTP operation-based Connector, the inbound property "Set-Cookie" only contains the first cookie and not an array with all cookies.
Can anybody tell me how I can access all cookies using the new HTTP Connector?
Maybe there is a way to retrieve the raw http header, to parse that?
The only other inbound properties the message has are content-length, http.reason, http.status, content-type, server and date.
This is a bug. You can check the fix versions there. Cannot think of any workarounds unfortunately.
As far as Anypoint studio is concerned, mulesoft blog says "Anypoint Studio 5.3 with Mule 3.7.2 released!". If possible have that downloaded and do let us know if the issue is fixed. It might help others too.
Related
I have a service like this
MPGW <===> WSP <===> Backend
On the response, I have an attachment which I was expecting the type to be 'XOP' but instead I'm getting 'MIME' . Is there any way I can over ride to XOP?
FYI...when I hit the service directly the back-end (by passing datapower), I'm getting XOP attachment type.
Processing MTOM with SOAP 1.1 is not supported in DataPower so make sure you are using SOAP 1.2.
You need to check if it is the WSP (likely) or the MPGW that is changing the response. This you can do using the Probe.
You can handle the attachments in a MTOM Policy for the service. Also use pass-through if possible for the MPGW to make sure it is not changing the payload.
I need to modify the ws url before it establishes a websocket connection.
I'm using #ManagedService in the server code and subscribing from client side using $.atmosphere.subscribe(request).
I've the following setup:
Cyberoam firewall --> Apache httpd(mod_proxy_ajp,mod_jk for load balancing) --> Glassfish
Primary Transport --> WebSocket
Fallback Transport --> long-polling
Problem I'm facing:
The Cyberoam firewall is having a limitation (in WAF) that the max characters in GET URL cannot exceeds 50 chars. But when I hit the subscribe in atmosphere, it is constructing the URL with all the X-Atmosphere-.. params along with it.
For e.g ws://localhost:8080/chat?X-Atmosphere-tracking-id=5ebed4c5-0b90-4166-88b2-9f273719ab75&X-Atmosphere-Framework=2.2.1-jquery&X-Atmosphere-Transport=websocket&Content-Type=application/json&X-atmo-protocol=true") which clearly exceeds the allowable limits.
I just need to know whether I can somehow construct the URL in my server code appending all the necessary headers and params before it connects?
Yes, I have set the attachHeadersAsQueryString:false while making the initial request, and obviously it doesn't connect with missing headers information while doing a WebSocket connection.
Any suggestions/thoughts would be greatly appreciated.
Thank You.
Use request.attachHeadersAsQueryString = false so mo query string will be passed. You may need to upgrade to the latest version of Javascript
https://github.com/Atmosphere/atmosphere-javascript
-- Jeanfrancois (Atmosphere's lead)
A JavaScript client that I have no control over is sending the incorrect HTTP request headers to my Web API services. More specifically, it's using a library that is sending an incorrect OData header.
Is there any way that I can intercept the HTTP request before it hits my services? Can I add/remove/update headers or query string info?
For instance, if I receive the following HTTP header:
GET /Some/API HTTP/1.1
Host: myhost.com:80
MaxDataServiceVersion: 2.0
I'd like to know how to modify it to the following before the OData libraries take over:
GET /Some/API HTTP/1.1
Host: myhost.com:80
MaxDataServiceVersion: 4.0
The header isn't incorrect. Your client expects an OData v2 service and even if you did manipulate the headers, it probably won't be able to understand the response from your server.
But you could use a simple HTTP proxy to rewrite the headers if you really want to try that route.
If you do that, make sure your OData server supports the Atom format because the OData JSON format changed completely between versions 2 and 4, so there's no way that JavaScript client will understand it. The Atom format changed as well, but if the client's parser is extremely lenient, it might work.
I have to use a 3rd party web service implemented in .NET 2.0 (on IIS, of course).
I have to make a java client. I am using wsdl2java to generate the SOAP stub.
As the original Apache Axis project now appears unmaintained, and I was having some problems parsing some responses from the service, I converted the client to use the latest (1.5) version of Axis2. Now, the .NET service won't even recognize my requests.
I managed to get the "chunking" turned off (where "stub" is a variable of type MumbleStub generated by wsdl2java, and I am showing what are several lines of code as one horrific line here):
stub._getServiceClient().getOptions().setProperty( HTTPConstants.CHUNKED, Boolean.FALSE);
.. so at least the service recognizes my request AS a request, albeit a bad one: "HTTP/1.1 400 Bad Request" is the response now (as opposed to an "intro / summary" page offering me a link to the WSDL).
I noticed that the Axis ("1") request had a different Content-TYpe header (text/xml, vs application/soap-xml), and I am wondering how to change this request header, if that is in fact the problem.
Alternately, has anybody else had this problem? Is the problem really the (undisplayable here, as it looks like "element injection" to the blog engine) ... xml version-"1.0" ... "XML meta intro tag" that Axis2 added to the beginning of the request?
WS-Deathstar, indeed.
As you mention the different content-type header I guess your client tries to send SOAP 1.2 requests and the 3rd party app only understands SOAP 1.1
Try changing the used soap version as AFAIK AXIS2 uses SOAP 1.2 by default
stub._getServiceClient().getOptions().setSoapVersionURI(org.apache.axiom.soap.SOAP11Constants.SOAP_ENVELOPE_NAMESPACE_URI);
I have a REST api that will accept a version via a custom HTTP header or a request parameter. I'm doing this because I don't want the URI to contain the version like del.icio.us .e.g http://server/api/v1/...
Now in my design, the HTTP header has a higher priority than the request param.
What happens then if the user does not supply any version at all ?
Should I default to the oldest version, or default to the latest version ?
Don't version the URI at all. Instead just version the representation. This way the client can decide which version of the API they want to use and it degrades well.
Example:
GET /contacts/3 HTTP/1.1
Accept: application/myapp-v2+xml
HTTP/1.1 200 OK
Content-Type: application/myapp-v2+xml
Why not simply make the version required and throw an error if it's not there?
If that's not an option then you have to go with the oldest version, otherwise if you upgrade and don't maintain backwards compatability you'll break existing clients.
Of course, if you don't mind breaking existing clients it might be more convenient to go with the latest version.
If your API defines specific URIs or URI naming conventions for accessing resources, your API is not RESTful. Versioning of URI construction is a non-issue for any REST API. Please see http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven for more information.