What is the default caching behaviour for Firebase Hosting with Cloud Run? - firebase-hosting

I have an HTTP service running in Cloud Run that I have mapped to Firebase Hosting using a wildcard to send all routes to the service.
// firebase.json
{
"hosting": [
{
"site": "mysite",
"rewrites": [
{
"source": "/**",
"run": {
"serviceId": "myservice",
"region": "europe-west2"
}
}
]
}
]
}
Update: I've also tried "source": "**" and config with or without the default static hosting using "public": "public" and the result is the same. The CDN appears to cache all content from Cloud Run by default.
The documentation for Firebase Hosting says: (bold my emphasis)
Any requested static content is automatically cached on the CDN. If you redeploy your site's content, Firebase Hosting automatically clears all your cached static content across the CDN until the next request.
However, because Cloud Functions and Cloud Run services generate content dynamically, the content for a given URL can vary based on such things as user input or the user's identity. To account for this, requests that are handled by backend code do not cache on the CDN by default.
However, within the browser developer Network tab I see cache hits (screenshot below):
Note the server: Google Frontend with x-cache: Hit indicating that the CDN served the content. I can confirm there are no Cloud Run logs for subsequent HTTP GET requests.
I've seen other articles online (one on medium) that says the opposite, that by default caching is enabled.
Is the Google documentation currently up to date? If so, what have I missed? I should mention that my HTTP service uses __session cookies for some routes. The example above was before any signin took place, so no cookies were sent from the browser.
I've also tested this using curl and I also get the same result:
> GET / HTTP/2
> Host: myhost
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< content-type: text/html; charset=utf-8
< server: Google Frontend
< x-country-code: GB
< accept-ranges: bytes
< date: Mon, 04 Oct 2021 13:17:19 GMT
< x-served-by: cache-lhr7335-LHR
< x-cache: HIT
< x-cache-hits: 1
< x-timer: S1633353439.260200,VS0,VE1
< vary: x-fh-requested-host, accept-encoding
< content-length: 11949
<
Hello world example
package main
import (
"fmt"
"log"
"net/http"
"os"
"time"
)
func main() {
log.Print("starting server...")
http.HandleFunc("/", handler)
port := os.Getenv("PORT")
if port == "" {
port = "8080"
log.Printf("defaulting to port %s", port)
}
// Start HTTP server.
log.Printf("listening on port %s", port)
if err := http.ListenAndServe(":"+port, nil); err != nil {
log.Fatal(err)
}
}
func handler(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "The time now is %s\n", time.Now())
}
FROM golang:1.17.1-alpine as builder
LABEL stage=builder
WORKDIR /app
COPY . .
RUN go build .
FROM alpine:latest
RUN apk --no-cache add tzdata
RUN mkdir -p /app/bin
WORKDIR /app
COPY --from=builder /app/helloworld ./bin
CMD ["/app/bin/helloworld"]
firebase.json
{
"hosting": {
"public": "public",
"ignore": [
"firebase.json",
"**/.*",
"**/node_modules/**"
],
"rewrites": [{
"source": "**",
"run": {
"serviceId": "helloworld"
}
}]
}
}
Curl output
CALLING CLOUD RUN DIRECTLY
andy#oak:~/projects/test-to-be-removed/public$ curl -v https://helloworld-q2ftkxvbva-uc.a.run.app/
* Trying 216.239.36.53:443...
* TCP_NODELAY set
* Connected to helloworld-q2ftkxvbva-uc.a.run.app (216.239.36.53) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.a.run.app
* start date: Sep 13 01:08:45 2021 GMT
* expire date: Nov 20 01:08:44 2021 GMT
* subjectAltName: host "helloworld-q2ftkxvbva-uc.a.run.app" matched cert's "*.a.run.app"
* issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1C3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55718a90ae10)
> GET / HTTP/2
> Host: helloworld-q2ftkxvbva-uc.a.run.app
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< content-type: text/plain; charset=utf-8
< x-cloud-trace-context: 4844f53bed45b95ba5c11f3873217904;o=1
< date: Mon, 04 Oct 2021 15:31:40 GMT
< server: Google Frontend
< content-length: 74
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
<
The time now is 2021-10-04 15:31:40.017735277 +0000 UTC m=+1034.166310273
* Connection #0 to host helloworld-q2ftkxvbva-uc.a.run.app left intact
CALLING CLOUD RUN VIA FIREBASE HOSTING (1st time Cache MISS)
andy#oak:~/projects/test-to-be-removed/public$ curl -v https://test-to-be-removed-c02e2.web.app/helloworld
* Trying 199.36.158.100:443...
* TCP_NODELAY set
* Connected to test-to-be-removed-c02e2.web.app (199.36.158.100) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=web.app
* start date: Sep 20 20:09:34 2021 GMT
* expire date: Dec 19 20:09:33 2021 GMT
* subjectAltName: host "test-to-be-removed-c02e2.web.app" matched cert's "*.web.app"
* issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1D4
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55ca2e032e10)
> GET /helloworld HTTP/2
> Host: test-to-be-removed-c02e2.web.app
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< content-type: text/plain; charset=utf-8
< server: Google Frontend
< x-cloud-trace-context: b62eb4e97a7e8dbd22b1958616455f27;o=1
< x-country-code: GB
< accept-ranges: bytes
< date: Mon, 04 Oct 2021 15:32:12 GMT
< x-served-by: cache-lhr7331-LHR
< x-cache: MISS
< x-cache-hits: 0
< x-timer: S1633361532.898050,VS0,VE234
< vary: x-fh-requested-host, accept-encoding
< content-length: 73
<
The time now is 2021-10-04 15:32:12.06951937 +0000 UTC m=+1066.218094364
* Connection #0 to host test-to-be-removed-c02e2.web.app left intact
CALLING CLOUD RUN VIA FIREBASE HOSTING (2nd time unexpected Cache HIT)
andy#oak:~/projects/test-to-be-removed/public$ curl -v https://test-to-be-removed-c02e2.web.app/helloworld
* Trying 199.36.158.100:443...
* TCP_NODELAY set
* Connected to test-to-be-removed-c02e2.web.app (199.36.158.100) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=web.app
* start date: Sep 20 20:09:34 2021 GMT
* expire date: Dec 19 20:09:33 2021 GMT
* subjectAltName: host "test-to-be-removed-c02e2.web.app" matched cert's "*.web.app"
* issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1D4
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x562f5255ae10)
> GET /helloworld HTTP/2
> Host: test-to-be-removed-c02e2.web.app
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< content-type: text/plain; charset=utf-8
< server: Google Frontend
< x-cloud-trace-context: b62eb4e97a7e8dbd22b1958616455f27;o=1
< x-country-code: GB
< accept-ranges: bytes
< date: Mon, 04 Oct 2021 15:32:14 GMT
< x-served-by: cache-lhr7371-LHR
< x-cache: HIT
< x-cache-hits: 1
< x-timer: S1633361534.332609,VS0,VE1
< vary: x-fh-requested-host, accept-encoding
< content-length: 73
<
The time now is 2021-10-04 15:32:12.06951937 +0000 UTC m=+1066.218094364
* Connection #0 to host test-to-be-removed-c02e2.web.app left intact

Related

API Gateway Returns HTTP 413 For GET Requests With No Body

My application is receiving an HTTP 413 "Request Entity Too Large" response from AWS API Gateway when sending a GET request to download a file.
While the requested file is > 29 MB in size, that is returned in the response, of course. As I understand it, an HTTP 413 pertains to the body of a request.
Why would API Gateway be returning an HTTP 413 if there is no body in the request?
Below are details from a curl command of the same URL my application uses.
curl -v https://api-gateway-host.us-east-1.amazonaws.com/path/to/file
* Trying <IP address>:443...
* Connected to api-gateway-host.us-east-1.amazonaws.com (<IP address>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.execute-api.us-east-1.amazonaws.com
* start date: Aug 24 00:00:00 2022 GMT
* expire date: Sep 22 23:59:59 2023 GMT
* subjectAltName: host "api-gateway-host" matched cert's "*.execute-api.us-east-1.amazonaws.com"
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f8fed80d400)
> GET /path/to/file HTTP/2
> Host: api-gateway-host.us-east-1.amazonaws.com
> user-agent: curl/7.77.0
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 413
< date: Thu, 27 Oct 2022 21:43:06 GMT
< content-type: application/json
< content-length: 38
< apigw-requestid: arw4qjGbIAMEMugqerq=
< vary: Origin
< vary: Access-Control-Request-Method
< vary: Access-Control-Request-Headers
< x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
< cache-control: no-cache, no-store, max-age=0, must-revalidate
< pragma: no-cache
< expires: 0
<
* Connection #0 to host api-gateway-host.us-east-1.amazonaws.com left intact
{"message":"Request Entity Too Large"}
Also, this same application, located in a different environment (QA), can make these same kinds of requests for the same file successfully.
The config has only one stage ($default), the route (ANY /path/{proxy+})integrates with an ALB, and has no authorizations.
I have reviewed the API Gateway configurations of the two environments, but cannot find any differences.
Thanks for your help!

Can't fix Paypal "invalid_client" authentication error

I'm trying to test my Paypal integration from localhost using Paypal Sandbox, but whenever I try to get an access token from Paypal, I get back the following error:
{
"error": "invalid_client",
"error_description": "Client Authentication failed"
}
I make the request with curl:
curl -v https://api.sandbox.paypal.com/v1/oauth2/token \
-H "Accept: application/json" \
-H "Accept-Language: en_US" \
-u "clientId:secret" \
-d "grant_type=client_credentials"
Obviously I am using the actual client id and secret in the request, and I am SURE I am using the correct client id and secret for the sandbox environment (I double checked).
Curl's verbose logs look like this:
curl -v https://api.sandbox.paypal.com/v1/oauth2/token \
> -H "Accept: application/json" \
> -H "Accept-Language: en_US" \
-u "clientId:secret" \
> -d "grant_type=client_credentials"
* Trying 173.0.82.78...
* TCP_NODELAY set
* Connected to api.sandbox.paypal.com (173.0.82.78) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal Production; CN=api.sandbox.paypal.com
* start date: Jul 27 00:00:00 2020 GMT
* expire date: Aug 1 12:00:00 2022 GMT
* subjectAltName: host "api.sandbox.paypal.com" matched cert's "api.sandbox.paypal.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
* SSL certificate verify ok.
* Server auth using Basic with user 'clientId' // The original log has the actual clientId here
> POST /v1/oauth2/token HTTP/1.1
> Host: api.sandbox.paypal.com
> Authorization: Basic QVRQZGl5TTFqeXpQZkdxMW9FQ2xnZG1uUE13VDRQM01yZEJ1MGRGWVZGLWRNVjk1X09xVjZVam1nNU5xRC0wR2ZPT1I3U1ZianYybWQzQXc6RURQSVdoREpPM0dkdndYNVlRaG45QzRCYzBlUTctaEpWZ041ZlVjUlpkbG1Ta0pMelhzZXE0TmpXeEZMV3kwcGdBNE5zTE5MZ1Qyc0pBVW0=
> User-Agent: curl/7.54.0
> Accept: application/json
> Accept-Language: en_US
> Content-Length: 29
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 29 out of 29 bytes
< HTTP/1.1 401 Unauthorized
< Cache-Control: max-age=0, no-cache, no-store, must-revalidate
< Content-Length: 77
< Content-Type: application/json
< Date: Wed, 07 Apr 2021 08:57:50 GMT
< Paypal-Debug-Id: 891f84363e502
< X-Paypal-Token-Service: IAAS
<
* Connection #0 to host api.sandbox.paypal.com left intact
{"error":"invalid_client","error_description":"Client Authentication failed"}
The problem seems to be here:
ALPN, server did not agree to a protocol
I have NO idea what it means. Could this have something to do with the fact that I'm testing from localhost? How can I fix this?
Decoding the base64 in the verbose log, the client ID passed is ATPdiyM1jyzPfGq1oEClgdmnPMwT4P3MrdBu0dFYVF-dMV95_OqV6Ujmg5NqD-0GfOOR7SVbjv2md3Aw
This does not work when testing at https://developer.paypal.com/demo/checkout/#/pattern/client , so it is not a valid ID.
( Link showing the error, "client-id not recognized for either production or sandbox" )
Create a new REST app, https://www.paypal.com/signin?intent=developer&returnUri=https%3A%2F%2Fdeveloper.paypal.com%2Fdeveloper%2Fapplications

HTTP/2 with Ubuntu 18.04

I would like to try HTTP/2 on this site: https://www.alebalweb-blog.com/
I recently updated the server to Ubuntu 18.04 with PHP 7.2, Apache/2.4.29, etc,etc
I did: sudo a2enmod http2
Added:
#HTTP/2
Protocols h2 h2c http/1.1
In my VirtualHost SSL.
and restarted Apache.
The SSL certificate is provided by Let's Encrypt.
The result is:
curl -k -v --http2 https://alebalweb-blog.com
* Rebuilt URL to: https://alebalweb-blog.com/
* Trying 45.76.70.142...
* TCP_NODELAY set
* Connected to alebalweb-blog.com (45.76.70.142) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=alebalweb-blog.com
* start date: Jul 7 02:02:06 2018 GMT
* expire date: Oct 5 02:02:06 2018 GMT
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: alebalweb-blog.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Fri, 13 Jul 2018 21:51:22 GMT
< Server: Apache/2.4.29 (Ubuntu)
< Upgrade: h2,h2c
< Connection: Upgrade
< Cache-Control: max-age=300
< Expires: Fri, 13 Jul 2018 21:56:22 GMT
< Vary: Accept-Encoding,User-Agent
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
Really strange I think is this:
Upgrade: h2,h2c
Connection: Upgrade
What does it mean?
HTTP/2 Test says:
HTTP/2 Test Result www.alebalweb-blog.com
Negative! www.alebalweb-blog.com does not support HTTP/2.0.
ALPN is not supported.
I feel like I missed something big... can you help me understand what?
I think I solved by switching to PHP-FPM
I used these codes:
apachectl stop
apt-get install php7.1-fpm # Install the php-fpm from your PHP repository. This package name depends on the vendor.
a2enmod proxy_fcgi setenvif
a2enconf php7.1-fpm # Again, this depends on your PHP vendor.
a2dismod php7.1 # This disables mod_php.
a2dismod mpm_prefork # This disables the prefork MPM. Only one MPM can run at a time.
a2enmod mpm_event # Enable event MPM. You could also enable mpm_worker.
apachectl start
from this guide: https://http2.pro/doc/Apache
and this guide: https://techwombat.com/enable-http2-apache-ubuntu-16-04/
and added "Protocols h2 h2c http/1.1" at the end of /etc/apache2/apache2.conf
Now the command curl -k -v --http2 https://alebalweb-blog.com reports this:
curl -k -v --http2 https://alebalweb-blog.com
* Rebuilt URL to: https://alebalweb-blog.com/
* Trying 45.76.70.142...
* TCP_NODELAY set
* Connected to alebalweb-blog.com (45.76.70.142) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=alebalweb-blog.com
* start date: Jul 7 02:02:06 2018 GMT
* expire date: Oct 5 02:02:06 2018 GMT
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x556ec5957940)
> GET / HTTP/2
> Host: alebalweb-blog.com
> User-Agent: curl/7.58.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Thu, 19 Jul 2018 20:21:38 GMT
< server: Apache/2.4.34 (Ubuntu)
< cache-control: max-age=300
< expires: Thu, 19 Jul 2018 20:26:38 GMT
< vary: Accept-Encoding,User-Agent
< content-type: text/html; charset=UTF-8
Above all you notice this changes: ALPN, server accepted to use h2, and HTTP/2 200
The site https://tools.keycdn.com/http2-test, says:
Yeah! www.alebalweb-blog.com supports HTTP/2.0.
ALPN supported.
And the development tools of opera and chrome indicate: h2
I only have one last doubt, in Google Webmaster tools, fetching the page as Google, I see this:
HTTP/1.1 200 OK
Date: Thu, 19 Jul 2018 20:35:35 GMT
Server: Apache/2.4.34 (Ubuntu)
Upgrade: h2,h2c
Connection: Upgrade, Keep-Alive
Cache-Control: max-age=300
Expires: Thu, 19 Jul 2018 20:40:35 GMT
Vary: Accept-Encoding,User-Agent
Content-Type: text/html; charset=UTF-8
Content-Length: 41422
Keep-Alive: timeout=5, max=100
I missing something? Or maybe need time?

PayPal Rest first call won't appear in sandbox transactions

I want to have a transaction that is completed and see it listed in my developer sand box. I think this transaction, below is completed but it is not in my sandbox transactions list. I followed the instructions on the paypal website for making a first call with the rest API.
Here are my two curl commands using my credentials and the returned access token. I received my state:created for the payment. But the transaction was not in my Sandbox Transactions. How long does it take to show up?
What am I doing wrong?
Thanks,
Harry
curl -v https://api.sandbox.paypal.com/v1/oauth2/token \
> -H "Accept: application/json" \
> -H "Accept-Language: en_US" \
> -u ".....:....." \
> -d "grant_type=client_credentials"
* About to connect() to api.sandbox.paypal.com port 443 (#0)
* Trying 173.0.82.78... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal Production; CN=api.sandbox.paypal.com
* start date: 2012-12-06 00:00:00 GMT
* expire date: 2016-12-06 23:59:59 GMT
* subjectAltName: api.sandbox.paypal.com matched
* issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)10; CN=VeriSign Class 3 Secure Server CA - G3
* SSL certificate verify ok.
* Server auth using Basic with user '......'
> POST /v1/oauth2/token HTTP/1.1
> Authorization: Basic .......... =
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: api.sandbox.paypal.com
> Accept: application/json
> Accept-Language: en_US
> Content-Length: 29
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 29out of 29 bytes
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< PROXY_SERVER_INFO: host=slcsbplatformapiserv3001.slc.paypal.com;threadId=384
< Paypal-Debug-Id: de62039a5a244
< SERVER_INFO: identitysecuretokenserv:v1.oauth2.token&CalThreadId=47502&TopLevelTxnStartTime=14b83d4e3f0&Host=slcsbidensectoken502.slc.paypal.com&pid=6295
< Date: Fri, 13 Feb 2015 16:45:42 GMT
< Content-Type: application/json
< Content-Length: 461
<
* Connection #0 to host api.sandbox.paypal.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
{"scope":"https://uri.paypal.com/services/subscriptions https://api.paypal.com/v1/payments/.* https://api.paypal.com/v1/vault/credit-card https://uri.paypal.com/services/applications/webhooks https://uri.paypal.com/services/invoicing https://uri.paypal.com/payments/payouts https://api.paypal.com/v1/vault/credit-card/.*","access_token":"A0151dMXKPrBCWFFucj132Nvw87sS5NFntFDhhfF8la3Wsg","token_type":"Bearer","app_id":"APP-80W284485P519543T","expires_in":28800}
$
$ curl -v https://api.sandbox.paypal.com/v1/payments/payment \
> -H 'Content-Type: application/json' \
> -H 'Authorization: Bearer A0151dMXKPrBCWFFucj132Nvw87sS5NFntFDhhfF8la3Wsg' \
> -d '{
> "intent":"sale",
> "redirect_urls":{
> "return_url":"http://example.com/your_redirect_url.html",
> "cancel_url":"http://example.com/your_cancel_url.html"
> },
> "payer":{
> "payment_method":"paypal"
> },
> "transactions":[
> {
> "amount":{
> "total":"7.47",
> "currency":"USD"
> }
> }
> ]
> }'
* About to connect() to api.sandbox.paypal.com port 443 (#0)
* Trying 173.0.82.78... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal Production; CN=api.sandbox.paypal.com
* start date: 2012-12-06 00:00:00 GMT
* expire date: 2016-12-06 23:59:59 GMT
* subjectAltName: api.sandbox.paypal.com matched
* issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)10; CN=VeriSign Class 3 Secure Server CA - G3
* SSL certificate verify ok.
> POST /v1/payments/payment HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: api.sandbox.paypal.com
> Accept: */*
> Content-Type: application/json
> Authorization: Bearer A0151dMXKPrBCWFFucj132Nvw87sS5NFntFDhhfF8la3Wsg
> Content-Length: 324
>
* upload completely sent off: 324out of 324 bytes
< HTTP/1.1 201 Created
< Server: Apache-Coyote/1.1
< PROXY_SERVER_INFO: host=slcsbplatformapiserv3001.slc.paypal.com;threadId=19925
< Paypal-Debug-Id: d2b2c56f78e41
< SERVER_INFO: paymentsplatformserv:v1.payments.payment&CalThreadId=196&TopLevelTxnStartTime=14b83d6cc6a&Host=slcsbpaymentsplatformserv3002.slc.paypal.com&pid=13409
< Content-Language: *
< Date: Fri, 13 Feb 2015 16:47:47 GMT
< Content-Type: application/json
< Content-Length: 740
<
* Connection #0 to host api.sandbox.paypal.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
{"id":"PAY-3XB52861RA479681CKTPCVMY","
create_time":"2015-02-13T16:47:47Z",
"update_time":"2015-02-13T16:47:47Z",
"state":"created",
"intent":"sale",
"payer":{"payment_method":"paypal",
"payer_info":{"shipping_address":{}}},
"transactions":[{"amount":{"total":"7.47","currency":"USD","details": {"subtotal":"7.47"}},"related_resources":[]}],"links":[{"href":"https://api.sandbox.paypal.com/v1/payments/payment/PAY-3XB52861RA479681CKTPCVMY","rel":"self","method":"GET"},{"href":"https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_express-checkout&token=EC-39015200YL315920D","rel":"approval_url","method":"REDIRECT"},{"href":"https://api.sandbox.paypal.com/v1/payments/payment/PAY-3XB52861RA479681CKTPCVMY/execute","rel":"execute","method":"POST"}]}
"payment_method":"paypal"
This means the user (your customer) must (these are the missing steps in above):
be redirected to Paypal from your application to the approval_url returned in the response (their response to your last curl call).
the user will/must "approve" your request
user will be sent back to your site/application to the url you set in return_url
you'll need to execute the payment after that.
Reference: Accept a PayPal payment
This essentially maps to "Express Checkout" in the Classic API.
Hth..

PayPal REST API: Requesting oauth token returns 500

Two days ago, something broke with our paypal integration. Unfortunately, trying to contact paypal support has proven to be of no help (no reply in 2 days), so I'll try my luck, here.
Requesting the token (curl https://api.paypal.com/v1/oauth2/token -H "Accept: application/json" -H "Accept-Language: en_US" -u "****:****" -d "grant_type=client_credentials") started ALWAYS returning an empty response and well, a 500 error.
Note that the same works just fine with api.sandbox.paypal.com and sandbox credentials.
I double checked our credentials and they are fine. Note as well, that it doesn't matter what credentials I use, it always returns the same - 500.
Here's the output of curl ... -v; looks like you have an internal server error, as the 500 shows:
* About to connect() to api.paypal.com port 443 (#0)
* Trying 173.0.88.98...
* connected
* Connected to api.paypal.com (173.0.88.98) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: /usr/ssl/certs/ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DES-CBC3-SHA
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal Production; CN=api.paypal.com
* start date: 201
* expire date: 201
* subjectAltName: api.paypal.com matched
* issuer: C=U
* SSL certificate verify ok.
* Server auth using Basic with user '****'
> POST /v1/oauth2/token HTTP/1.1
> Authorization: Basic ****
> User-Agent: curl/7.27.0
> Host: api.paypal.com
> Accept: application/json
> Accept-Language: en_US
> Content-Length: 29
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 29 out of 29 bytes
* additional stuff not fine /usr/src/ports/curl/curl-7.27.0-1/src/curl-7.27.0/lib/transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 500 Internal Server Error
< Server: Apache-Coyote/1.1
< Date: Thu, 28 Mar 2013 15:59:53 GMT
< Content-Length: 0
< Connection: close
<
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
Thanks!
This is something that is currently being looked into. If you have not already opened a ticket with PayPal MTS I would advise opening up a ticket with Technical Support, so that your issue can be added to the examples. You will also then be notified once the issue has been resolved.
edit: This is now resolved as of 04:12 AM GMT (31/03/2013).