Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
I get a guzzle error as above , when i am sending the following code from a drupal 8 site:
$url="https://mywebsite.com/index.php";
$client = \Drupal::httpClient();
$client->setDefaultOption( array('verify' ,false));
$post_data = $form_state->cleanValues()->getValues();
$request = $client->post($url, $post_data);
This line was causing it to think this was the URL. When I took it out it works okay
$client->setDefaultOption(array('verify', false));
Basically, it should work (because the $url obviously is a string).
If it doesn't, check the stack trace of the exception (is it this call, or maybe another?).
And provide the Guzzle version please.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'd like to see if an HTTPURLResponse statusCode begins with 2 to indicate success. Does it make more sense to see if it falls between 200 and 299, inclusive? Or does Swift have a builtin function to see if an HTTP status code represents success?
That is, given,
var statusCode: Int = ..
which, if any, of the following expressions would be preferred?
let success = String(statusCode).prefix(1) == "2"
let success = statusCode < 300 && statusCode >= 200
The relevant documentation reads,
The first digit of the Status-Code defines the class of response. The
last two digits do not have any categorization role. There are 5
values for the first digit:
- 1xx: Informational - Request received, continuing process
- 2xx: Success - The action was successfully received,
understood, and accepted
- 3xx: Redirection - Further action must be taken in order to
complete the request
- 4xx: Client Error - The request contains bad syntax or cannot
be fulfilled
- 5xx: Server Error - The server failed to fulfill an apparently
valid request
https://www.ietf.org/rfc/rfc2616.txt
You are right that anything between 200 and 299 (inclusive) means success.
However, it's not a complete picture. A 3XX response might mean that you don't know if the request is successful yet, and you need to follow the redirect to find out what the real status was.
A 303 redirect can lead to a URI that returns a 404, or a 200 OK.
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
Here's my header:
Accept: 'application/json',
'Content-Type': 'application/json',
'Cache-Control': 'no-cache',
'x-apikey': 'some-api-key',
When I send a GET request with the query /users?q={"firstname": {"$regex": "jo"}} after refreshing the page with ctrl+f5, the response match the query. When after that first request, I try another query: /users?q={"firstname": {"$regex": "nat"}}, the request to the server is successful (200), but the body response is the same than for the first query. I have to manually press ctrl+F5 to make the answer match the query, and it works kind of randomly, I'm not able to understand any logic. Get resquests like /users?skip=25&max=25 works perfectly, so must be link to the use of the query string params.
I try all the possibilities of 'Cache-Control, but nothing worked.
thanks!
Sorry, but this was due to an aggressive cache on a particular service, should be working fine now.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I have Postman collection to run POST request 10 iterations, in each iteration I have different values for the variables in the request body, and I am doing that by using CSV.
After completing running the collection, I cannot see the "Response Body" for each iteration. it shows data for the test results and statistics, but not for the actual response body.
Is there any idea to how I can get the response body for each request/iteration in the collection, is that not available in Postman, is there any other tools can do that?
More simplistic way is:
tests[`Response Body: ${responseBody}`] = true;
In the latest version (5.5.0) you can see the response data for each request by clicking on the request name in the Collection Runner. This will give you the details about the request made and the response received.
You can get the response body like this in your test section:
const body = pm.response.json();
Then you can print it in your test results as:
tests["Response Body ", body] = true;
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to replicate the following command line curl:
curl -F file=#myfile.csv 'https://myserver/api/import/data_save.html'
Does anyone have an example in either www::curl or lwp perhaps? I have been trying all day and it's not even worth me posting my tries at this point, it would only confuse things. Thank you!!!
I think you are asking how to submit a form with a file field named file populated with the contents of file myfile.csv.
use LWP::UserAgent qw( );
my $ua = LWP::UserAgent->new();
my $response = $ua->post('https://myserver/api/import/data_save.html',
Content_Type => 'form-data',
Content => [
file => [ 'myfile.csv' ],
],
);
die($response->status_line)
if !$response->is_success;
The arguments to $ua->post are documented in HTTP::Request::Common.
Well, let's unpack what that curl command actually does, because -F implies a lot.
It sets the HTTP method of the request to POST.
It sets the Content-Type of the request to multipart/form-data.
It composes a MIME multipart request body with the form metadata indicating that the "file" input is being provided from a file named "myfile.csv", as well as a part containing the actual file contents.
Here's how to replicate that using WWW::Curl:
use WWW::Curl::Easy;
use WWW::Curl::Form;
my $curl = WWW::Curl::Easy->new;
my $form = WWW::Curl::Form->new;
$form->formaddfile('myfile.csv', 'file', "multipart/form-data");
$curl->setopt(CURLOPT_URL, 'https://myserver/api/import/data_save.html');
$curl->setopt(CURLOPT_HTTPPOST, $form);
my $response = $curl->perform;
But LWP is probably easier; see ikegami's answer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Wanted to get your opinion on this, probably there's isn't an absolute right answer, but I want to see what you think is the more correct approach.
If there's nothing structurally wrong with a request (it's in the correct format) and all the fields are valid (field values not too long, required fields have a value etc...) but the call failed because of a business reason, for example "you cannot change a status of task that isn't assigned to you", what should be the response in this case:
200 with a JSON which explains the error:
{
error: {
code :120,
message: "you cannot change a status of a task that isn't assigned to you"
}
}
or maybe a 4xx response with a similar body:
{
error: {
code :120,
message: "you cannot change a status of a task that isn't assigned to you"
}
}
While I want to agree with #EJK, the spec he linked is out of date.
The most current one is RFC7231: https://www.rfc-editor.org/rfc/rfc7231#section-6.5.1 which changed the meaning of the old 403 FORBIDDEN response status.
Answer:
So for the sake of this question 400 BadRequest should be used, because whoever consumed your service, case being the client, is wrong and can possible fix his request
The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something that is perceived to be
a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).
An example from your own use case:
The client now knows that the error "you cannot change a status of a task that isn't assigned to you" is his own fault. And he may even try to issue a different new (valid) request.
403 Forbidden seems like a good match.
From http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.4.
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated. If
the request method was not HEAD and the server wishes to make public
why the request has not been fulfilled, it SHOULD describe the reason
for the refusal in the entity. If the server does not wish to make
this information available to the client, the status code 404 (Not
Found) can be used instead.
Thus, option 2, as you have proposed, seems good as it also describes the reason for the failure.