Verified
Status Update
No update yet.
Comments
pi...@google.com
Not starting yet? It's already "Early in March" enough (Mar/14/2018 PDT)
iv...@playnext-lab.co.jp
Masashi & all, thank you for enquiring about this.
The opt-in period has been moved to April 2018. We'll be sure to update this thread when closer from the exact milestones.
The opt-in period has been moved to April 2018. We'll be sure to update this thread when closer from the exact milestones.
he...@webenable.nl
As outlined in the recent release notes for the Maps Android API [https://developers.google.com/maps/documentation/android-api/releases ], this feature is now available for the new basemap style.
To opt-in, add the following tag to your AndroidManifest.xml file, within the <application> tags. The user's device must have at least Google Play Services version 12.0.0 in order for the opt-in to work.
<meta-data android:name="com.google.android.gms.maps.API_OPTIONS" android:value="B3MWHUG2MR0DQW"/>
To opt-in, add the following tag to your AndroidManifest.xml file, within the <application> tags. The user's device must have at least Google Play Services version 12.0.0 in order for the opt-in to work.
<meta-data android:name="com.google.android.gms.maps.API_OPTIONS" android:value="B3MWHUG2MR0DQW"/>
st...@google.com
The new basemap style will switch from opt-in to opt-out within the next few weeks.
Should you wish to temporarily opt-out, add the following tag to your AndroidManifest.xml file, within the <application> tags:
<meta-data android:name="com.google.android.gms.maps.API_OPTIONS" android:value="B3H9HE845CFHYG"/>
We will keep posting updates here closer to date.
Should you wish to temporarily opt-out, add the following tag to your AndroidManifest.xml file, within the <application> tags:
<meta-data android:name="com.google.android.gms.maps.API_OPTIONS" android:value="B3H9HE845CFHYG"/>
We will keep posting updates here closer to date.
ku...@gmail.com
The switch from opt-in to opt-out of the new basemap look for the Maps Android API will be effective within the next 24 hours.
st...@google.com
The new basemap look is now live for the Maps Android API. Please look at https://developers.google.com/maps/documentation/android-api/releases .
he...@webenable.nl
@jh... Is v12 of com.google.android.gms:play-services-maps required in build.gradle for the opt-out to work?
I'm using:
implementation 'com.google.android.gms:play-services-places:11.8.0'
...and my device is running:
Google Play Services App: 12.6.85 (040400-197041431)
.. but I still see POI icons on the map when adding the opt-out within <application> tags.
I'm using:
implementation 'com.google.android.gms:play-services-places:11.8.0'
...and my device is running:
Google Play Services App: 12.6.85 (040400-197041431)
.. but I still see POI icons on the map when adding the opt-out within <application> tags.
ku...@gmail.com
Nevermind, I believe I had incorrect expectations of the opt-out. Looking at https://mapsplatform.googleblog.com/2018/02/updated-basemap-style-for-google-maps.html , I believe POI icons previously existed, but were circular instead of pins (I was incorrectly expecting the POI icons to disappear completely). So, in that case, it seems to be working as intended, as the opt-out does return them to the circular icons.
ku...@gmail.com
Please note that the opt-out period will end on October 31st. Your app will only display the updated basemap style after that.
an...@janmyr.com
The opt-out period has ended as of November 1st. Your app will now only get the updated basemap stye.
Updated Release Notes are available at:https://developers.google.com/maps/documentation/android-api/releases .
Updated Release Notes are available at:
bj...@vipscasino.com
This is a deal breaker for us as well :(
wl...@google.com
Sorry for the inconvenience.
We are actively working on fixing this issue.
We are actively working on fixing this issue.
er...@ultracode.com
Same problem here. The Chrome and Firefox debug tools both show NO content-encoding header from the "Google Frontend" server on gzipped text/html responses. As a result I just see garbage in the browsers. The image that I'm testing against works fine everywhere *except* in Cloud Run. It even works fine in the cloud shell when I run the back-end standalone there or via the in-shell dockerd and access it through the Web Preview link. This is a show-stopper for me, can't use Cloud Run until there's a fix or some kind of work-around for the issue.
wl...@google.com
This issue is specifically for 'content-encoding: br'
'content-encoding: gzip' is supposed to be functioning, do you mean it's not working for you?
'content-encoding: gzip' is supposed to be functioning, do you mean it's not working for you?
er...@ultracode.com
For what it's worth, I'm running a sample SAFE stack (https://safe-stack.github.io/ ) app, largely unmodified, as generated by the dotnet core SAFE template ("dotnet new SAFE ..."). The container image is built with dotnet core 3.1 on Linux and uses the mcr.microsoft.com/dotnet/core/aspnet:3.1 base image.
I just did some additional testing and it seems I was mistaken about the image's web server returning gzipped HTML. It appears now that it chooses Brotli when it has that option in the request headers. For example, hitting a local deployment's index.html page, I see in Chrome devtools:
Content-Type: text/html
Server: Kestrel
Transfer-Encoding: chunked
Content-Encoding: br
... and no content-length, oddly enough... but the page renders OK.
Whereas when I hit the Cloud Run deployment of the same image, I see in Chrome devtools the response headers:
content-length: 314
content-type: text/html
server: Google Frontend
status: 200
vary: Accept-Encoding
... but no content-encoding header. I see binary data on the page.
So I can't say one way or another whether the issue exists with gzipped responses, but there's definitely some sort of problem with Brotli as others have reported here.
Feel free to PM me for more info if needed. I'm happy to run tests.
I just did some additional testing and it seems I was mistaken about the image's web server returning gzipped HTML. It appears now that it chooses Brotli when it has that option in the request headers. For example, hitting a local deployment's index.html page, I see in Chrome devtools:
Content-Type: text/html
Server: Kestrel
Transfer-Encoding: chunked
Content-Encoding: br
... and no content-length, oddly enough... but the page renders OK.
Whereas when I hit the Cloud Run deployment of the same image, I see in Chrome devtools the response headers:
content-length: 314
content-type: text/html
server: Google Frontend
status: 200
vary: Accept-Encoding
... but no content-encoding header. I see binary data on the page.
So I can't say one way or another whether the issue exists with gzipped responses, but there's definitely some sort of problem with Brotli as others have reported here.
Feel free to PM me for more info if needed. I'm happy to run tests.
wl...@google.com
We believe the issue has been resolved. Please give it a try.
er...@ultracode.com
This problem seemed to have been resolved several days ago. I'm glad to hear an official announcement of the fact. I can confirm that the "Google Frontend" is now returning the expected content-encoding header, at least for Brotli-encoded HTML ...
< HTTP/2 200
< content-type: text/html
< vary: Accept-Encoding
< content-encoding: br
< server: Google Frontend
< content-length: 314
....and browsers are much happier for it. Thanks for the fix.
wl...@google.com
Thanks for testing. We are glad that the fix unblocks your use case!
ad...@gmail.com
Hello I am having an issue with that its not returning Content-Encoding: as gzip.
And I cant find any resources on how can we achieve it in Cloud Run as we were planning to move from App Engine where it is done out of the box for us
And I cant find any resources on how can we achieve it in Cloud Run as we were planning to move from App Engine where it is done out of the box for us
wl...@google.com
Hi, Cloud Run infrastructure doesn't compress the response by default. We suggest make the application compress the response.
Description
I'm serving gzip and brotli compressed files from my Node server, with a static file server that chooses what to serve based on the accept-encoding request header.
Outside of Cloud Run this works fine. If the accept-encoding header includes `gzip` or `br`, the pre-compressed file is served, the content-encoding response header is set, and the file (HTML in this case) renders fine in the browser.
On Cloud Run however, the accept-encoding request header is received, and the server selects the brotli compressed file, and the server sets the content-encoding response header, but the content-encoding header never makes it to Chrome, and so the brotli'ed HTML file is rendered as junk.
App Engine standard docs mention that some headers are stripped:
This includes the accept-encoding request header and the content-encoding response header. It might be the case that some of this applies to Cloud Run, but it's only the content-encoding header being stripped. This causes a problem where the server thinks is can send brotli, but it can't.
What you expected to happen:
Either both accept-encoding and content-encoding are stripped, or neither are, and the behavior is documented.
I'd prefer that the content-encoding header is _not_ stripped, since my assets are highly compressible.