I am sending a POST request to a WCF Web service using fiddler, and the service responds with HTTP 400: The request has an invalid header name.
The post request looks like this:
User-Agent: Fiddler
Host: localhost:49392
Content-Type: application/json
Content-Length: 0
{ "clientFirstName" : "John"}
My endpoint is defined as follows:
[OperationContract]
[System.ServiceModel.Web.WebInvoke
(Method = "POST",
RequestFormat = WebMessageFormat.Json,
ResponseFormat = System.ServiceModel.Web.WebMessageFormat.Json,
BodyStyle = System.ServiceModel.Web.WebMessageBodyStyle.Wrapped,
UriTemplate = "MakeReservation")]
String MakeReservation(Stream reservationStream);
MORE
First of all, the JSON was in the wrong pane. I moved it to the Request Body pane.
I changed the prototype of the function to take a String instead of Stream as the input parameter. The service now accepts my call and returns 200, but in the debugger I see that the input parameter String is null. When I change it back to Stream, I get 400 again.
YET MORE
Enable tracing gives me at trace file with the following message:
Incoming message for operation 'MakeReservation' (contract 'ITalLimoService' with namespace
'http://tempuri.org/') contains an unrecognized http body format value 'Json'. The expected body
format value is 'Raw'. This can be because a WebContentTypeMapper has not been configured on the
binding. See the documentation of WebContentTypeMapper for more details.
As noted int the WebInvoke definitiuon, both the RequestFormat and ResponseFormat are set to WebMessageFormate.Json. Why is IIS complaining about this?
I don't know why this works, but for some reason removing the following line from the fiddler Composer did the trick:
Content-Type: application/json
And that is that. I would give points for an explanation.
I know this post is old. But very strange, when I removed the header "application/json" it worked.
Has it got to do with server setup?
The request could not be understood by the server due to deformed syntax. The client SHOULD NOT repeat the request without modifications.If request to your server with data that is in the correct format, but its bad data. eg: a Posted String value to an API endpoint that expected a String value; but, the value of the string contained data that was something else.
The syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains syntactically correct but semantically wrong XML instructions.
Related
I have one API that returns information in JSON, and for that, I would indicate that the content-type of the HttpResponse is application/json.
So, with Rikulo, I have something like :
connect.response.headers.set(HttpHeaders.CONTENT_TYPE, contentTypes['json']);
But when I request my API, it told me that the headers are immutable.
HttpException: HTTP headers are not mutable
#0 _HttpHeaders._checkMutable (http_headers.dart:267:21)
#1 _HttpHeaders.set (http_headers.dart:31:18)
Therefore, how can I set my response headers, or there is a native solution with Rikulo to return JSON data ?
You can set the contentType property directly:
connect.response.headers.contentType = contentTypes["json"];
If you'd like to set the header instead, you have to pass a String object (which Dart SDK expects):
connect.response.headers.set(HttpHeaders.CONTENT_TYPE,
contentTypes['json'].toString());
But the error message shall not be as you posted. Like Kai suggested in the comment, the message indicates you have output some data before setting the header.
I have a wcf service defined like this:
[OperationContract]
[WebInvoke(Method = "POST", ResponseFormat = WebMessageFormat.Json)]
public CreateOrderResponse CreateOrder(CreateOrderRequest request)
The request parameter is populated fine, but inside my method a what to access HttpContext.Current.Request.InputStream to get the raw post body but the InputStream is empty, InputStream.Lenght is 0.
My question is why is Request.InputStream empty when the request parameter is populated fine from the post request?
You need to use the CreateOrderRequest instance and it's associated properties.
As far as I know, and I may be wrong, the Inputstream would always be null as it has been processed prior to being passed to your WCF method. See this link for more information Capturing raw HTTP POST Data during Exception
httpclient, httpmime 4.1.3
I am trying to upload a file through http to a remote server with no success.
Here's my code:
HttpPost method;
method = new HttpPost(solrUrl + "/extract");
method.getParams().setParameter("literal.id", fileId);
method.getParams().setBooleanParameter("commit", true);
MultipartEntity me = new MultipartEntity();
me.addPart("myfile", new InputStreamBody(doubleInput, contentType, fileId));
method.setEntity(me);
//method.setHeader("Content-Type", "multipart/form-data");
HttpClient httpClient = new DefaultHttpClient();
HttpResponse hr = httpClient.execute(method);
The server is Solr.
This is to replace a working bash script that calls curl like this,
curl http://localhost:8080/solr/update/extract?literal.id=bububu&commit=true -F myfile=#bububu.doc
If I try to set "Content-Type" "multipart/form-data", the receiving part says that there's no boundary (which is true):
HTTP Status 500 - the request was rejected because no multipart boundary was found
If I omit this header setting, the server issues an error description that, as far as I discovered, indicates that the content type was not multipart [2]:
HTTP Status 400. The request sent by the client was syntactically incorrect ([doc=null] missing required field: id).
This is related to [1] but I couldn't determine the answer from it. I was wondering,
I am in the same situation but didn't understand what to do. I was hoping that the MultipartEntity would tell the HttpPost object that it is multipart, form data and have some boundary, and I wouldnt set content type by myself. I didn't quite get how to provide boundaries to the entities - the MultipartEntity doesn't have a method like setBoundary. Or, how to get that randomly generated boundary to specify it in addHeader by myself - no getBoundary methor either...
[1] Problem with setting header "Content-Type" in uploading file with HttpClient4
[2] http://lucene.472066.n3.nabble.com/Updating-the-index-with-a-csv-file-td490013.html
I am suspicious of
method.getParams().setParameter("literal.id", fileId);
method.getParams().setBooleanParameter("commit", true);
In the first line, is fileId a string or file pointer (or something else)? I hope it is a string. As for the second line, you can rather set a normal parameter.
I am trying to tackle the HTTP Status 400. I dont know much Java (or is that .Net?)
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error
I have a WCF service defined like this:
[ServiceContract(Namespace = "http://AttributeServiceNameSpace", Name = "AttributeServiceName1")]
public interface IHelloIndigoService1
{
[OperationContract(Name="AttributeOperationName11", Action = "aaa2")]
String HelloIndigo11();
[OperationContract(Name = "AttributeOperationName12", Action = "aaa1")]
String HelloIndigo12();
}
And I captured the HTTP message during the service invocation, as below.
POST http://xxx/Service.svc/IHelloIndigoServiceAddress1 HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "aaa2"
Host: shao-02.fareast.corp.microsoft.com
Content-Length: 162
Expect: 100-continue
Connection: Keep-Alive
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<AttributeOperationName11 xmlns="http://AttributeServiceNameSpace"/>
</s:Body>
</s:Envelope>
So we can see the Action and Operation Name both exist in the SOAP message to invoke the service.
But I just wonder:
Why do we need the Action and the Operation Name to identify a single service method? Only one should be enough.
You don't need Action and OperationName to identify service operation. Operation name defines structure (wrapper element name) of the SOAP message but it is not used for operation identification. The action is used for operation identification.
There are some non standard SOAP parsers using operation name (root body element) for operation identification but those parsers don't use SOAP action.
Edit: I had a discussion with my colleague today and it looks like my previous answer isn't correct. The real unique identification of the message in SOAP protocol is SOAP Action + Root element. So in this case the Action defines SOAP Action and OperationName defines wrapper element's name (used as root message element).
I am building a REST service on WCF, and one of the methods I am writing is GetProfile, which will return the profile for a given username. The username will include the user's domain, and so will have the following format: "DOMAIN\username".
I therefore have a service called Profiles.svc, which has the following endpoint set up:
[OperationContract]
[WebGet(UriTemplate = "/{username}", ResponseFormat = WebMessageFormat.Xml)]
IRestResponse GetProfile(String username);
However, when I attempt to visit the service at http://server/profiles.svc/DOMAIN%5cusername (%5c is the urlencoded form of a backslash) I get the following error:
Server error in '/' Application
HTTP Error 400 - Bad Request
This occurs even when there is no code actually defined in my implementation of GetProfile, so I believe the error is being thrown at the point WCF attempts to bind the URI to a method.
Are there some settings I need to add to my web service configuration in order to allow backslashes to be added to URLs in a REST WCF service? Or are backslashes simply not allowed?
I suspect that they are simply not allowed in that part of the url. They are fine in the query string as long as they are encoded. As a general rule i wouldn't put anything in the path part of the url that is invalid in filename (i.e. ?).
Perhaps you could use a different character to deliminate th domain from the username.
You could also seperate the username into domainname and username and use the normal path deliminator '/'. I'm not familar with the this enough to know if this is how you do it for sure, but this would be my best guess.
[OperationContract]
[WebGet(UriTemplate = "/{domainName}/{username}", ResponseFormat = WebMessageFormat.Xml)]
IRestResponse GetProfile(String domainName, String username);