Skip to content

warn if usePost is undefined (close #613) - #615

Closed
Chris Sherlock (chrissherlock) wants to merge 2 commits into
snowplow:masterfrom
chrissherlock:master
Closed

warn if usePost is undefined (close #613)#615
Chris Sherlock (chrissherlock) wants to merge 2 commits into
snowplow:masterfrom
chrissherlock:master

Conversation

@chrissherlock

Copy link
Copy Markdown
Contributor

Sorry about before, this patch should hopefully be better.

Comment thread src/js/out_queue.js
{
Console.warn('usePost undefined');
path = '/i';
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't we have

usePost = typeof usePost != 'undefined' && usePost && window.XMLHttpRequest && ('withCredentials' in new XMLHttpRequest());

What do you think Anton Parkhomenko (@chuwy) ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to see a warning. One of the orgs who uses this has managed to encode an absolutely massive object and because this variable is undefined they are using GET requests... and thus is getting 414 errors because the URI is enormous... if they picked up on the fact that they hadn't set usePost, then it would have alerted them to the issue more quickly.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if I understand it right - if website-owner just wants to use GET-requests with reasonable payload - we'll force all of his users see "usePost undefined" message in console, which doesn't look right for me. So, this change is not about undefined-check it's more about GET-check. But correct me if I'm wrong.

I'm quite against all log messages from tracker - in 99,9% of cases they hit console-aware users and not website-owners. But I'm quite keen to introduce something like debug-mode for tracker, where all such cases can be safely printed in development-environment and deleted in production.

If we want to avoid 414-like issues - all we can do is to be more explicit in tracker documentation.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another way to fix it would be to use POST by default and allow to use GET by settings useGet = true, but this is quite big change for me, taking in account that CloudFront collector doesn't support POST.

@snowplowcla Snowplow CLA bot (snowplowcla) added the cla:yes [Auto generated] Snowplow Contributor License Agreement has been signed. label Oct 26, 2017
@snowplowcla

Copy link
Copy Markdown

Chris Sherlock (@chrissherlock) has signed the Individual Contributor License Agreement. Thanks so much

@alexanderdean

Copy link
Copy Markdown
Member

Agree with Anton Parkhomenko (@chuwy) - we won't add warnings into a production tracker. Debug mode is the way to go.

@mhadam Michael Hadam (mhadam) added the category:debug-only A debug mode only feature. label Nov 27, 2018
@paulboocock

Copy link
Copy Markdown
Contributor

This has been superseeded by eventMethod and it is no longer possible to get into a situation where usePost is undefined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

category:debug-only A debug mode only feature. cla:yes [Auto generated] Snowplow Contributor License Agreement has been signed.

Development

Successfully merging this pull request may close these issues.

7 participants