Closed yalisassoon closed 9 years ago
Does this not mean that when using HTTP GET, base64Encoded is always set to true? if so, what is the purpose of allowing users to set it in the tracker constructor? Shouldn't it be based on the HTTP verb set in the emitter?
When using HTTP GET, if base64Encoded is set to true, then we send the context as cx={{base64-encoded JSON}}
. If base64Encoded is set to false, then we send the context as co={{uri-encoded JSON}}
. Either way, we do some prep work to ensure that the querystring doesn't get corrupted...
got it.
Do the characters []/ also need encoding?
For Base64 encoding, we use the URL-safe variant. For URI-encoding - we just use the standard.
It looks like RFC 1738 frowns on { and } as well (section 2.2): http://tools.ietf.org/html/rfc1738
So I'm guessing that the Java URI decoder is failing on those, so we need to URI encode those too.
For Base64-url-safe, the doco is here: https://tools.ietf.org/html/rfc4648#page-7
fixed in commit 00fa373e76701447a307fc9051f624236f85769d
After we fix a bug, should we assign it to someone for testing or should we simply close it?
For the 0.1.0, closing is fine
I can see lines in the bad rows bucket that fail because e.g. the
{
character can be found on the query string, when a custom context is sent into Snowplow without being base64 encoded: