POST doesn't work but GET does

[Chris Boyce]

I am assuming that I a missing something stupid but I can't get the POST to work.  Here is what I am sending:

POST /debug/collect HTTP/1.1
Host: www.google-analytics.com
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded

v=1&tid=UA-59xxxxxx-1&cid=19128xxxxx.14301xxxxx

and here is what I get back:

{

    "hitParsingResult": [

        {

            "valid": false,

            "parserMessage": [

                {

                    "messageType": "ERROR",

                    "description": "A value is required for parameter 'v'. Please see http://goo.gl/a8d4RP#v for details.",

                    "messageCode": "VALUE_REQUIRED",

                    "parameter": "v"

                },

                {

                    "messageType": "ERROR",

                    "description": "A value is required for parameter 'tid'. Please see http://goo.gl/a8d4RP#tid for details.",

                    "messageCode": "VALUE_REQUIRED",

                    "parameter": "tid"

                },

                {

                    "messageType": "ERROR",

                    "description": "A value is required for parameter 'cid'. Please see http://goo.gl/a8d4RP#cid for details.",

                    "messageCode": "VALUE_REQUIRED",

                    "parameter": "cid"

                }

            ],

            "hit": "GET /debug/collect HTTP/1.1"

        }

    ]

}

If I change it to a GET call and add the data in the query parameters everything works great.  I would prefer not to use GET if possible.  I have read the docs and I believe I am doing everything correctly so I am at a loss.

Thanks 

[Avi Mehta]

Hi Chris,

Is there an empty line in your post request? That might be causing the hit to not validate. 

For me, When I do 

curl --data 'v=1&tid=UA-5912345-1&cid=19128.123'  https://google-analytics.com/debug/collect

The response is correct but when I do 

curl --data '\nv=1&tid=UA-5912345-1&cid=19128.123'  https://google-analytics.com/debug/collect

The response is incorrect. 

Regardless, I think the validation server can handle this scenario better and I'll open a bug internally to fix this. Thanks for reporting the issue!

--
You received this message because you are subscribed to the Google Groups "google-analytics-measurement-protocol" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-analytics-measure...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Boyce]

I don't believe there is any white spaces.  I did a test using both POSTMAN and Fiddler.  The example in my original past was a copy paste straight from the preview on POSTMAN and there are no white spaces.  I can't copy/paste as easily from Fiddler but I verified that there are no white spaces there either. 

[Avi Mehta]

Installed postman and tried to do this again. I am not sure if you are seeing the same issue or not... but can you check if following works? 

When I enter www.google-analytics.com/debug/collect as the url in postman, the request got redirected to https:// and lost the query params in the process. To fix this, I changed the url to https://www.google-analytics.com/debug/collect and then started to get the right response. (in your case, you are missing the dp param).

Please let me know if this solves your use-case. I'll try to figure out if we should fix the lost-params-on-redirect bug. We'll fix it if needed.

--

[Chris Boyce]

Wow, I didn't even pay attention to the fact it did a 302 but I see that now.  I followed your suggestion and switched it to https and it looks like it works.

BTW, I was following the instructions found here and it just lists the url as http mode.  Not sure if the 302 is just a /debug/collect thing or not but if it is not an update to the docs might be in order.

Thanks again for your help.

On Tuesday, May 5, 2015 at 10:29:42 AM UTC-7, Chris Boyce wrote:

[Avi Mehta]

yes. /debug/collect is https only. I discussed the preserving-of-parameters-on-redirect and a coworker pointed out that even if we did preserve the query params, redirect to a post request won't work. Hence I am inclined to not fixing this. When people encounter this, we hope that they see the redirect and start sending data securely after that.

Sending actual data via measurement protocol works over both http and https for now so the article you pointed to is accurate as well :)

--