My application is running the free hobby-dev program and free hobby-dev database (https://orandno.herokuapp.com/Files).
If I send a small file in POST body all fine, but if the file is big I recieve error H18 - Server Request Interrupted.
My code in golang on sever side now do almost nothing:
func DBUploadFile(c *gin.Context) {
c.JSON(200, gin.H{"Uploaded": "OK"})
return
}
Heroku staff wrote me "There is not a limit on filesize for uploads"...
But why error H18 arise?
Heroku gave more reason why you might end up with that error, which I will advice you read for more clarification H18 - Server Request Interrupted, but this answer should also solve your issue.
Related
I deploy my Laravel + vue project on the Digitalocean apps and some of my api are working but some are not.
When I look into the api response I received message: "Server Error",
But the api is working on localhost and gives error after the deployment.
Is there a way to view the actual error message of the api reponse? so that I can easily understand what causing the error and fix it.
But I really find it weird that it causing error in the digitalocean apps, but works on my local machine.
I've tried searching for hours how to view the errors but I can't find it.
please help me. Thank you!
You can log in to your server and look in the file storage/logs/laravel.log.
Otherwise, I would suggest using a service such as Bugsnag or Sentry, which have integrations with laravel and will give you a dashboard with all your errors
Some people suggest putting APP_DEBUG to true, but that is a security risk as your customers will be able to see the error as well, and you should never do this on a production server
I'm running Laravel 6.20.0 and I'm experiencing the following error since yesterday when my queue worker is trying to send an email:
Swift_TransportException: Expected response code 250 but got an empty response in public_html/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php:448
I've tried requeuing my emails several times now since yesterday, but I keep on receiving the same error when it attempts to send. This worked flawlessly before for almost a year, so I'm a bit confused what is causing this issue. I haven't changed any credentials nor changed any code or configuration recently.
My mail settings are as follows:
MAIL_DRIVER=smtp
MAIL_HOST="smtp-relay.gmail.com"
MAIL_PORT=587
MAIL_USERNAME="my#user.name"
MAIL_PASSWORD="myapppassword"
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS="my#from.address"
MAIL_FROM_NAME="My Name"
I've doubled checked in my Google Admin that both the IPv4 address as well as the IPv6 address of my server are whitelisted and the SMTP relay service is enabled. I also created a new App password within my Google account to see if that would fix the problem - but no luck there.
I've also cleared the config cache (and have tried php artisan config:cache) and tried restarting supervisor which runs the worker running the task for the email queue. I've also tried requeueing the emails one by one in case I triggered some kind of throttling, but to no avail. By no means is my website sending many emails, about a 100 a month, well within the limits posed by my email account. (And I currently got <10 stuck in queue.)
As a last resort I turned off SMTP verification and TLS encryption in the Google Admin, so the only requirement for using the SMTP was having the IP address whitelisted (which it is). But this didn't work either, so I've switched SMTP verification and TLS encryption back on again as a requirement.
Finally; I ran a composer update, but that didn't fix the problem either.
I've found some other older threads on Stackoverflow with a similar problem, but I had already tried all offered solutions as described above.
What am I missing?
i think you need change mail port to 25 like this :
MAIL_PORT=25
Just faced same issue.
In my case SMTP sending worked when I tried to send an email without queues.
But when I tried to send same email with same config using queue, I got error that looks like:
[2021-02-15 12:43:24] local.ERROR: Expected response code 250 but got an empty response {"exception":"[object] (Swift_TransportException(code: 0): Expected response code 250 but got an empty response at /app/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php:448)
[stacktrace]
#0 /app/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php(345): Swift_Transport_AbstractSmtpTransport->assertResponseCode('', Array)
#1 /app/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/EsmtpTransport.php(305): Swift_Transport_AbstractSmtpTransport->executeCommand('HELO [127.0.0.1...', Array, Array, false, NULL)
#2 /app/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php(368): Swift_Transport_EsmtpTransport->executeCommand('HELO [127.0.0.1...', Array)
#3 /app/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/EsmtpTransport.php(341): Swift_Transport_AbstractSmtpTransport->doHeloCommand()
#4 /app/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php(148): Swift_Transport_EsmtpTransport->doHeloCommand()
After long research I've found that issue is related with HELO command itself.
As you can clearly see in the log, for some reason (probably server hostname) there is 127.0.0.1 IP address, which Google is blocking.
How I resolved that:
So to resolve that, I've added one little line in my artisan file:
$_SERVER['SERVER_NAME'] = 'mydomain.com';
So my artisan file looks like this now:
#!/usr/bin/env php
<?php
$_SERVER['SERVER_NAME'] = 'mydomain.com';
define('LARAVEL_START', microtime(true));
...
Spoke with Google Workspace rep
As a temporary solution they asked to use
smtp.gmail.com instead of smtp-relay.gmail.com
Worked on 2 of our projects.
P.S. The limit is 130 emails per account on Workspace (former Gsuite)
for example if you have 5 users, 5x130=650
What the rep said haha :)
I have a controller that is doing something, everything seems fine, it logs a success, and then it does this
return new ResponseEntity<>(resp, HttpStatus.OK);
Seems like it should send a 200 OK.
Well, I also have a HandlerInterceptorAdapter with an "afterCompletion" that logs the status:
logger.debug("Response status: {}, URI: {}", response.getStatus(), request.getRequestURI());
This is showing a 500 where there was a success from the controller.
In the stdout logs I see an error
2018-01-12 12:33:59.035 ERROR 18952 --- [pr-8080-exec-14] o.s.boot.web.support.ErrorPageFilter : Cannot forward to error page for request [/ws/path] as the response has already been committed.
As a result, the response may have the wrong status code. If your application is running on WebSphere Application Server you may be able to resolve this problem by setting com.ibm.ws.webcontainer.invokeFlushAfterService to false
and
org.apache.catalina.connector.ClientAbortException: java.io.IOException: APR error: -32
I can't find any doc on what that APR error is and I have no idea why the status code would be wrong. I am using tomcat 8.5.
So. APR -32 is a "Client Abort" error. The client was timing out in waiting. It looks like what was happening was the client made a request and was sitting in queue for a few seconds. It has a short hard timeout limit. The client timed out before the server got to the request. Then the server picked up the request and did everything fine but when trying to write back to the client, it found the socket closed. So it set a 500 and threw that exception.
In my go application I am getting the following error: "http: server closed idle connection". I would like to catch it and retry my http connection if it's encountered.
I found that this error comes from the "net/http" package and furthermore from the transport implementation. In particular it's defined here
I get it wrapped in url.Error but this is all I was able to find out. Do you know how I can actually catch this error?
Edit:
I am using elastic search client, which in turn is using the net/http. From the client I get the above mentioned error and would like to retry my elastic search request as being transient. For now the way I am catching transient errors is:
if urlErr, ok := err.(*url.Error); ok && (urlErr.Temporary() || urlErr.Err == io.EOF) {
return retryRequest()
}
Comments in net/http/transport.go say this (located here):
if err == errServerClosedIdle {
// The server replied with io.EOF while we were trying to
// read the response. Probably an unfortunately keep-alive
// timeout, just as the client was writing a request.
return true
}
Go will attempt to retry the request if it finds a non-nil http.Request.GetBody (found here), so I think it is expected to retry the request (or provide a GetBody function).
As for the leading error cause, you might want to check server's keep-alive functionality, my guess is that server is sending TCP connection reset (interpreted as io.EOF) prematurely. You might want to try disabling keep-alives and see if that changes anything.
As Gray Fox mentioned, Go will usually retry these requests. However, this is not the case for requests that aren't "idempotent". I was running into a few of these errors on POST requests, and after searching around I found this Github issue that says:
The HTTP Transport would normally retry those requests, but because they're POST requests they're not idempotent and Go conservatively assumes it might be unsafe to retry them.
Later in the issue someone mentioned that many banking APIs use some variant of the Idempotent-Key header to make them "safe". Stripe is a company that uses that header, and this is what their API docs say about it:
The API supports idempotency for safely retrying requests without accidentally performing the same operation twice.
So there you go, that's what the header is for.
In short, if you want Go's HTTP Transport to retry POST requests (and other non-idempotent requests), you need to include either the Idempotency-Key or X-Idempotency-Key header. That doesn't necessarily make those requests idempotent, but it will make them retry-able from net/http's perspective.
Links:
Source code check for the Idempotency-Key headers - https://github.com/golang/go/blob/2cd2ff6f564dce5be0c4fb7f06338ff7af3fc9a9/src/net/http/request.go#L1401)
Github issue where I found this information: https://github.com/golang/go/issues/19943
Can any one tell me why I'm getting this error with codeigniter when it comes to sending mail.
some time it work fine some times i get this error
451 Please try again later
The following SMTP error was encountered: 451 Please try again later
Unable to send email using PHP SMTP. Your server might not be configured to send mail using this method.
Are you sure your SMTP server is working fine at the time you get this error? If it works sometimes, then that means that your configuration is probably fine. I'd deploy the code of a test server online and then run your code to see if its really a configuration problem or maybe a problem with the SMTP host that you're trying to send the mail through.