search

snowplow / snowplow-gtm-server-side-client

A Google Tag Manager Server-side Client template for collecting events using the Snowplow JavaScript Tracker
https://snowplowanalytics.com
Apache License 2.0
9 stars 3 forks source link

Serving of Snowplow library not possible for Cloud Run sGTM installations #34

Closed awoehrl closed 6 months ago

awoehrl commented 1 year ago

Hi!

When using Cloud Run instead of AppEngine for sGTM, trying to load the Snowplow JS library throws an 502 error. The root cause seems to be that Cloud Run doesn't include a content-encoding=gzip header in the response. AppEngine adds this automatically. (https://www.simoahava.com/analytics/custom-gtm-loader-server-side-tagging/#commento-568ba0c7ae603cac4a54ec5eba335fb110b8164b9ff2406ed9d212f6d9a5a5b1)

Best Andreas

adatzer commented 1 year ago

Thank you for raising @awoehrl ! That is definitely something to look into for next release!

adatzer commented 8 months ago

Hi @awoehrl! There is indeed an issue with the HTTP headers related to how the client stores them in template data storage. In addition, at the moment the Client does not relay any content-negotiation (based on Accept-Encoding). More specifically, the request to jsDelivr has no such header.

This means that:

  1. Currently the sp.js is not encoded/compressed neither when transfered from jsDelivr to SS-Client, nor from SS-Client to e.g. a browser. This shouldn't create any problem in most (if not all) expected cases, since the identity representation is expected to be accepted. Still this is not ideal (see below).
  2. Given (1), adding any Content-Encoding header value (e.g. gzip as suggested in the issue description) when there is no compression implemented would be incorrect.

As mentioned, the current state is not ideal because:

  1. Is based on the assumption that the "identity"/"no encoding" representation is not unaccepted
  2. No content negotiation means no compression even if acceptable by the user agent(browsers) and supported by the server(jsDelivr)

On the other hand (issue #40 aside), the current Client behaviour is simple and not really incorrect. Still, since we know (based on the Vary response header from CDN) that the Accept-Encoding header is the only one influencing the content of sp.js, we could possibly go a step further here, so leaving this issue open for now.

adatzer commented 6 months ago

Resolved as part of https://github.com/snowplow/snowplow-gtm-server-side-client/issues/40 . Closing.