Does HttpRequest support setting the protocol version? I would like to set it to 2.0. Is it possible?
For example, HttpWebRequest has a ProtocolVersion property, but can only be set to 1.0 or 1.1.
Does HttpRequest use any default version? Will it work with HTTP/2?
If my server only supports HTTP/2, will I get an error if I use HttpRequest?
The company is going to be updating systems, to be compatible with HTTP/2. I am looking at some code, and we use HttpRequest, and I have noticed there is no option to set the protocol version. Will this be an issue?
I have also noticed in the code we specify:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Related
I'm trying to understand the difference between the http package and the HttpClient class in the dart:io library. My purpose is to known when I should use which. I see both of them used to apparently do the same thing.
I've seen these Q&As:
Choosing between package:html, dart:html, dart:io (class HttpClient) and package:http APIs to fetch HTTP resources
How to make HTTPS request using HttpClient in dart?
In a Dart console application, is there a library for an HTTP Request that doesnt require DOM access?
How to do POST in Dart command line HttpClient
This is what I think is true so far but my understanding is fuzzy:
http is high level and HttpClient is low level (source)
http can make post requests but HttpClient can't (source)
both http and HttpClient (with HttpClientRequest) can make GET and POST requests (source)
both http and HttpClient can be used on the client and the server
So to sum it up, I would say that each one can do anything that the other can as well, but it is easier to use the http package since this one is more high-level. Is that summary correct?
The http package is an abstraction over dart:io and dart:html.
So if you want to share code between browser and other platforms that makes HTTP requests, then it's best to use the http package. Then the code will just work everywhere.
If you don't care about the browser use what API you like best. In Flutter the http package just wraps dart:io's HttpClient.
How we can control over the number of header going with the HTTP request? e.g.; If I don't want to send the "Cache-Control" header,how to control it?
I am using HttpClient for sending a JSON formatted request.
Using 4.5.1 version of org.apache.httpcomponents and 3.1 version of commons-httpclient in maven dependencies.
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.
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.