3 ms·
From the blog post: The source of the requests is our client-side JavaScript error tracking code, which installs a global JavaScript error handler and attempts
by mootothemax 15y ago
From the blog post:
The source of the requests is our client-side JavaScript error tracking code, which installs a global JavaScript error handler and attempts to POST to our server when unhandled errors are detected on the client.
Sounds like Googlebot's executing more advanced Javascript, though it's pretty scary it's allowing POSTs to go through.
- dpark 15y agoI think it'd be silly to block POSTs in cases like this. The page makes an unsolicited POST. It's quite reasonable for any crawler to do the same. How else would they get an accurate representation of what the user sees? Now, if Google is sending random forms, as another commenter claims, that's a different case. But unsolicited POSTs coded in the page's scrips? Send 'em.
- troyk 15y agoI believe the HTTP spec defines a GET as a representation of a resource and a POST as modifying or updating a resource, so google bot doing POSTS is not very neighborly.
- dpark 15y agoBy that definition, unsolicited POSTs are not very neighborly.
- chc 15y agoI don't see how. Updating a view count or putting a pin on a "countries that have visited this page" map is fairly benign. Trying to randomly scribble on somebody else's data is not.
- regularfry 15y agoIf all the Googlebot is doing is executing the JS as an arbitrary user's browser would, and part of that page load JS involves doing a POST, I can see the argument for doing it.
- 16bytes 15y agoAgree. Otherwise a page could dynamically load html via AJAX and give a totally different view to a user than what google-bot sees.