I can't figure out why I'm getting this error in Dart:
HttpException: HTTP headers are not mutable
I have an instance of HttpResponse and I try to add some headers to it:
response.outputStream.writeString(responseData);
response.headers.add('Content-Type', 'text/html');
response.outputStream.close();
What am I supposed to do then if not add to the headers?
It's simple to solve, just make sure you add headers before outputting anything:
response.headers.add('Content-Type', 'text/html'); // <-- this line first.
response.write(responseData);
response.close();
All I did was change the order of the lines.
The reason is that if you start outputting the body, you can't simply modify the headers anymore (because the headers are already sent down the wire!). This is how HTTP works. First the headers then the body.
More background:
Sometimes HTTP libraries (generally in different programming languages) may be buffering the output data and do not flush the content immediately, resulting in a scenario where you can seemingly modify the headers even after outputting something. In your case that's not happening. The output seems to be flushed already.
Related
Let's say we gave a generic POST request with Python's requests.
req = requests.post('http://someapi.someservice.com', files=files)
req will be a Response object. In my case, the .content of the response can be very, very large so I do not wish to read it all into memory. Luckily, requests provides an iterator .iter_content that allows iteration over the contents. My question is, though, does req contain all contents of the response already (and as such everything is already read into memory), or does calling .content and as such .iter_content initiate a download which really fetches the content? This is important, because if assigning the POST request to a variable already reads the Response's content into memory, then of course using .iter_content makes no difference.
You will need to set the stream parameter to True in your request in order to avoid downloading the entire content of the response into the response object:
req = requests.post('http://someapi.someservice.com', files=files, stream=True)
Excerpt from the documentation of Body Content Workflow:
By default, when you make a request, the body of the response is
downloaded immediately. You can override this behaviour and defer
downloading the response body until you access the Response.content
attribute with the stream parameter... You can further control the workflow by use of the Response.iter_content() and Response.iter_lines() methods.
I'm working with a really strange (and nasty) API that I have no control over, and unfortunately when an invalid request is made, instead of responding with a 4xx status, it responds with a 200 status instead.
With this response, it also changes the response body from the usual XML response to plain text, but does not change the content type header. You can imagine how annoying this is!
I've got Siesta working with the API and the fact that it is no actually RESTful in the slightest, but I'm unsure how to get the next part working - handling the unsuccessful requests.
How do I go about transforming a technically valid and successful 200 response, into an error response? Right now I have the following setup:
configure("/endpoint") {
$0.mutateRequests { req in
... perform some mutation to request ...
}
$0.pipeline[.parsing].add(self.XMLTransformer)
}
configureTransformer("/endpoint") {
($0.content as APIResponse)
.data()
.map(Resource.init)
}
This is working just fine when the response actually is XML, however in the scenario where the response is an error, I receive the following:
bad api request: invalid api key
or something similar to this. The XMLParser class is already handling this, and in turn marks itself as having come across an error, however I don't know how to make Siesta realise that there is an error, and to not call my transformer but instead mark the request as failed to I can handle the error elsewhere.
How can I achieve what I'm after?
configureTransformer is just a common-case shortcut for the full-featured (but more verbose) arbitrary transformers Siesta’s pipeline supports. Full transformers can arbitrarily convert any response to any other, including success → failure and failure → success. The user guide discusses this a bit.
You can see this in action in the example project, which has a customer transformer that does something very similar to what you want, turning a 404 failure into a success with the content false. It is configured here and defined here. That example does a failure → success transformation, but you should find the code adaptable for your success → failure purposes.
I'm trying to post a user status update to the Goodreads API.
Most of the time my request returns 200 OK and does nothing. Every now and then, though, it returns 201 Created and the status is updated. When it works it's always the first time I try to make the call after running the app in iOS simulator. Subsequent calls never work.
I don't think the problem is the API itself, since the official Goodreads iOS app uses the same call and it always works.
Their API is famous for having problems with calls that include brackets in the parameters, but I can make other calls that contain brackets and they work fine, the problem is just this one.
I'm using OAuthSwift and this is my code:
oAuth.client.post(
"http://www.goodreads.com/user_status",//.xml",//?user_status[book_id]=6366035&user_status[page]=168",
parameters: ["user_status[page]" : 168, "user_status[book_id]" : 6366035, "format" : "xml"],
//headers: ["Content-Type" : "application/x-www-form-urlencoded"],
success: {
data, response in
print("")
print(response)
},
failure: {
error in
print("")
print(error)
}
)
(The commented out parts are alternatives I have tried unsuccessfully.)
I'm printing the base string that gets signed and it looks the same for the calls that work and the ones that don't, except for the nonce and the timestamp, obviously.
In the headers is also included the oauth_signature, which changes every time and sometimes contains characters that are encoded by OAuthSwift, so that could account for the call working just some of the time (it could work only when the signature doesn't contain a certain character)… but I'm printing out the headers too and I don't see any patterns or any discernible difference between the headers of the calls that work and those of the calls that don't.
So now I don't know what to test anymore… I'm checking the base string and the headers for calls that work and for calls that don't and they look the same… Could anybody think of something else that changes between calls and I should check? I have no idea what could be causing this and I don't know how to debug it.
Thanks in advance,
Daniel
Edit: Very weird… I tried my request with Paw, a Mac REST client, and with Chrome's Postman extension. If I use https I get 404 on my first call, then 201 on the second, then 404 on the third, 201 on the forth and so on. It works every other time. The time it works it doesn't matter if I use http or https, it works as long as there was a failed https request just before.
So I tried doing the same in my app: I added two https calls one after the other… in my app they always return 404.
So it seems like Postman, Paw and OAuthSwift are handling the requests differently. I don't know what could be the difference between those clients… the signature base string seems to be the same for all three, the headers too… so what else could change between them?
In the newer versions of Xcode you can only communicate with a HTTPS server. I expect Google support that so you can change the URL. Or you can edit your Info.plist file.
App Transport Security Settings > Allow Arbitrary Loads > YES
I'm using MSXML2_TLB.pas generated from the Microsoft XML type library to call a pretty simple web-service, so I don't need the full XML wrapping and just do this:
var
r:XMLHTTP;
begin
r:=CoXMLHTTP.Create;
r.open('POST',WebServiceURL,false,'','');
r.setRequestHeader('Content-Type','application/xml');
r.send('<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" '+
'xmlns:ns="http://somebigcorporation.com/api/ws1/">'+
'<soapenv:Body>'+
//snip: irrelevant to the question
'</soapenv:Body></soapenv:Envelope>');
if r.status<>200 then raise Exception.Create(r.statusText);
Result:=(r.responseXML as DOMDocument).documentElement.firstChild.firstChild.selectSingleNode('importantData');
end;
The webservice responds nicely with status 200 and Content-Type: text/xml; charset=iso-8859-1.
In some cases, documentElement is nil (and the above code throws an access violation). Apparently responseXML exists, but only to offer a parseError object (it says so in the docs), and parseError.reason in these cases is An invalid character was found in text content..
Why is the parser not taking the 'charset' value from the response header? Is there a way to tell the XMLHTTP instance to use the charset value from the response header?
Update: I don't know if it's important, but the response also doesn't start with <?xml and even if it did I have no way to request/modify it so it would have an encoding="iso-8859-1" attribute.
I think you need to set the charset in the request so the result is correct.
r.setRequestHeader('Content-Type', 'application/xml; charset=ISO-8859-1');
I'm implementing a REST API using ASP.NET MVC, and a little stumbling block has come up in the form of the Expect: 100-continue request header for requests with a post body.
RFC 2616 states that:
Upon receiving a request which
includes an Expect request-header
field with the "100-continue" expectation, an origin server MUST
either respond with 100 (Continue) status and continue to read
from the input stream, or respond with a final status code. The
origin server MUST NOT wait for the request body before sending
the 100 (Continue) response. If it responds with a final status
code, it MAY close the transport connection or it MAY continue
to read and discard the rest of the request. It MUST NOT
perform the requested method if it returns a final status code.
This sounds to me like I need to make two responses to the request, i.e. it needs to immediately send a HTTP 100 Continue response, and then continue reading from the original request stream (i.e. HttpContext.Request.InputStream) without ending the request, and then finally sending the resultant status code (for the sake of argument, lets say it's a 204 No Content result).
So, questions are:
Am I reading the specification right, that I need to make two responses to a request?
How can this be done in ASP.NET MVC?
w.r.t. (2) I have tried using the following code before proceeding to read the input stream...
HttpContext.Response.StatusCode = 100;
HttpContext.Response.Flush();
HttpContext.Response.Clear();
...but when I try to set the final 204 status code I get the error:
System.Web.HttpException: Server cannot set status after HTTP headers have been sent.
The .NET framework by default always sends the expect: 100-continue header for every HTTP 1.1 post. This behavior can be programmatically controlled per request via the System.Net.ServicePoint.Expect100Continue property like so:
HttpWebRequest httpReq = GetHttpWebRequestForPost();
httpReq.ServicePoint.Expect100Continue = false;
It can also be globally controlled programmatically:
System.Net.ServicePointManager.Expect100Continue = false;
...or globally through configuration:
<system.net>
<settings>
<servicePointManager expect100Continue="false"/>
</settings>
</system.net>
Thank you Lance Olson and Phil Haack for this info.
100-continue should be handled by IIS. Is there a reason why you want to do this explicitly?
IIS handles the 100.
That said, no it's not two responses. In HTTP, when the Expect: 100-continue comes in as part of the message headers, the client should be waiting until it receives the response before sending the content.
Because of the way asp.net is architected, you have little control over the output stream. Any data that gets written to the stream is automatically put in a 200 response with chunked encoding whenever you flush, be it that you're in buffered mode or not.
Sadly all this stuff is hidden away in internal methods all over the place, and the result is that if you rely on asp.net, as does MVC, you're pretty much unable to bypass it.
Wait till you try and access the input stream in a non-buffered way. A whole load of pain.
Seb