I'm using react-use-hotjar and I can see from adding logging call backs that hotjar is successfully initialising with the correct site id and identifyHotjar calls are working also. However, no recordings are showing up in the hotjar dashboard.
In the network tab I can see;
POST https://ws3.hotjar.com/api/v2/sites/[my-site-id]/recordings/content => 413 Request Entity Too Large
this request does have the following header: Content-Length: 16748416
which admittedly does seem large - but if I'm uploading video to hotjar I'm kind of expecting that to be reasonably large - so wouldn't this end point be configured to accept large payloads?
I can also see another failing request;
POST https://in.hotjar.com/api/v1/sites/[my-site-id]/deferred-page-content/[some-other-id] => 413
which also has this header: content-length: 16331099 - again pretty big.
Further background - I am running this site on my localhost and exposing it via local tunnel - I'm not sure if that make a difference
Has anyone come across this? I've googled it but I can't find anyone else talking about a 413 from hotjar.
Related
I am trying to make a POST request to an endpoint served using jetty server. The request errors out saying 413 Request entity too large. But the content-length is only 70KB which I see is way below the default limit of 200KB.
I have tried serving via ngnix server and add client_max_body_size to desired level but that didn't work. I have set the setMaxFormContentSize of WebContext and that didn't help either. I have followed https://wiki.eclipse.org/Jetty/Howto/Configure_Form_Size and that didn't helped me either.
Does anyone have any solution to offer?
wiki.eclipse.org is OLD and is only for Jetty 7 and Jetty 8 (long ago EOL/End of Life). The giant red box at the top of the page that you linked it even tell you this, and gives you a link to the up to date documentation.
If you see a "413 Request entity too large" from Jetty, then it refers the the Request URI and Request Headers.
Note: some 3rd party libraries outside of Jetty's control can also use HttpServletResponse.sendError(413) which would result in the same response status message as you reported.
Judging by your screenshot, which does not include all of the details, (it's really better to copy/paste the text when making questions on stackoverflow, screenshots often hide details that are critical in getting a direct answer), your Cookie header is massive and is causing the 413 error by pushing the Request Headers over 8k in size.
Jmeter 2.12.
I used a scenario fully functional in front of a reverse proxy Apache. Recently we 've replaced the reverse proxy with the F5 BIGIP technology and now my scenario hangs.
The problem is for a particular ajax POST request the HTTP response is truncated : i receive a 200 OK but the HTML content is not full (no html tags for example). When i post the same request with Firefox the full content is ok.
Note that i don't receive the http header Transfer-Encoding: chunked.
In this case what can be the difference between Firefox and JMETER ?
Anyone have an idea on how could i get the full html response ?
Thanks for any reply.
That completely depends on the settings on your F5 and what exactly you mean with "response is truncated" and "no html tags". Do you get the correct response but the html tags are stripped out? or is the response just truncated so you i.e. only get the first n bytes?
The best way to find out what is actually going wrong is to use something like fiddler in between and try to find the real difference between the responses, especially regarding the response headers (Content-Length, Transfer-Encoding, etc).
When you found the actual difference please post here so we can help you further.
On a sidenote, by any chance do you have some custom coding on the f5 (iRules) which react to different user-agent settings?
Given you send identical requests you should be receiving identical responses.
Use JMeter's View Results Tree listener to inspect request details, or even better compare requests which are being sent by Firefox and JMeter using a lower level network sniffer tool like Wireshark, detect the differences and configure JMeter accordingly to send the same request(s) as Firefox does.
The other reason might be JMeter truncating large response, by default JMeter displays "only" first 10 megabytes in the View Results Tree listener, if this is the case - you can add the next line to user.properties file:
view.results.tree.max_size=0
and restart JMeter to pick the property up - it will suppress response truncation and you will be able to view the full response data.
Alternative way of setting the property is passing it via -J command line argument like:
jmeter -Jview.results.tree.max_size=0 ....
References:
Full list of command-line options
Apache JMeter Properties Customization Guide
Getting a 416 error when trying to GET a website with HTTParty. Works just fine in the browser.
I have never gotten this error before, so I went online and found this:
It occurs when the server is unable to fulfill the request. This may
be, for example, because the client asked for the 800th-900th bytes of
a document, but the document is only 200 bytes long.
The request includes a Range request-header field, and not any of the
range-specifier values in this field overlaps the current extent of
the selected resource, and also the request does not include an
If-Range request-header field.
Wondering if anyone has gotten 416 with HTTParty before and if there is a way to prevent this form happening. Thanks
Example website where error occurs:
http://www.bizjournals.com/jacksonville/blog/morning-edition/2014/07/teens-make-up-less-of-summer-workforce-than-ever.html
It appears that bizjournals is able to detect you are a bot (not accessing in the browser) and therefore returns a 416.
irb(main):005:0> HTTParty.get('http://www.bizjournals.com/jacksonville/blog/morning-edition/2014/07/teens-make-up-less-of-summer-workforce-than-ever.html').body
=> "........As you were browsing <strong>http://www.bizjournals.com</strong> something about your browser made us think you were a bot. There are a few reasons this might happen........"
You could either ask bizjournals to allow you to make requests or try to change the headers to make bizjournals think you are not a bot.
I'm currently using Team Foundation Server and WSS 3.0 as the Team Portal. After the installation and configuring, I noticed the application was very slow sometimes, taking minutes to load a page. Then I googled it and found n solutions, none solved my problem.
Using Firebug I noticed I was getting a lot of 401 errors, mostly in _layouts and _themes folders.
Error image: http://i.stack.imgur.com/SmurI.jpg
Authentication method is NTLM
Any clue on what's happening? The page loads, it just takes forever before showing up.
EDIT: Here's fiddler statistics:
Request Count: 161
Bytes Sent: 144.851 (headers:133249; body:11602)
Bytes Received: 400.222 (headers:69769; body:330453)
ACTUAL PERFORMANCE
Requests started at: 09:47:55.449
Responses completed at: 09:50:03.311
Aggregate Session time: 00:03:11.542
Sequence (clock) time: 00:02:07.8627850
TCP/IP Connect time: 239ms
RESPONSE CODES
HTTP/401: 84
HTTP/200: 74
HTTP/302: 2
HTTP/404: 1
RESPONSE BYTES (by Content-Type)
application/x-javascript: 218.048
~headers~: 69.769
text/html: 37.837
image/gif: 31.467
text/css: 27.506
image/png: 10.133
image/jpeg: 3.937
text/javascript: 1.007
text/xml: 518
We have had exactly this problem with a sharepoint site.
The root cause is the way that NTLM works. The NTLM handshake is a 401.2 401.1 followed by a 200. Allways 3 requests for each file.
For each request, the web server will send a request to the AD server. The problem is that by default there is only 2 connections to the AD server. So the request get backed up and retried.
There are two things that you can do:
Make sure that you are caching the gif files (then you will not have to get them all the time)
Switch to Kerberos
Edit
For setting up Kerberos have a look at this blog post http://blogs.msdn.com/b/martinkearn/archive/2007/04/23/configuring-kerberos-for-sharepoint-2007-part-1-base-configuration-for-sharepoint.aspx
Did you look at this common SharePoint performance fix?
Can you verify this happens on all clients? If you access the page from a browser on the server itself, do you still get this result?
If you haven't yet, turn off IPv6 in your network settings. Also, verify your DNS settings. Slow AD authentication + RPC Server Unavailable leads me to believe you may have addressing issues. Does everything seem responsive from a ping? When you log on to your machine, does it take a long time to log in (another symptom of DNS setting problems)?
if you are 401 errors on CSS / js / Images / .axd. with sharepoint /
NTLM authentification
You must configure the anonymous access on the webapplication and if you have a publishing portal activate the anonymous on :
- style library
- sitecollectionimage
I came across this problem with css files I downloaded. For some reason, the windows setting "encrypt contents to secure data" was checked for some files. After removing this setting, everything went fine. Be sure to unblock them if necessary.
(just to be sure: I'm talking about (file)->properties->advanced->encrypt data...)
I have 3 AJAX functions to move data between a Django app on my website and some JavaScript using YUI in the browser. There is not a major difference between them in terms of their structure, concept, code, etc. 2 of them work fine, but in the 3rd one, I get one spurious HTTP request immediately after the intended request. Its POST data contains a subset of the POST data of the intended request. The request meta data is identical except for the CONTENT_LENGTH (obviously) and the CONTENT_TYPE which is 'text/plain; charset=UTF-8' for the intended and 'application/x-www-form-urlencoded' for the unwanted request. I do not set the content type explicitely at all which seems to suggest both requests do not have the same origin and the second one just pops out of thin air.
The intended request sets HTTP_CACHE_CONTROL': 'no-cache' and 'HTTP_PRAGMA': 'no-cache', the spurious one does not. The dev server log output for both requests is
[15/Feb/2010 15:00:12] "POST /settings/ HTTP/1.1" 200 0
What does the last 0 at the end mean ? Could not find any documentation on that. This value is usually non-zero... In Apache, it is the total size in bytes of the server response, can someone confirm it's the same for Django ?
My problem obviously is to find out where this additional request comes from.
I am fairly familiar with JS debugging using Firebug and I think I'm good at Python and Django, but I do not know a lot about the internals of HTTP requests and responses. I can breakpoint and step through the JS code that sends the intended XMLHTTP request, but that breakpoint does not get hit again.
The problem occurs with both FF3 and Safari, I'm on Snow Leopard, so I can't test with IE or Chrome.
I've looked at Django debugging techniques and tools like http://robhudson.github.com/django-debug-toolbar/ but I think I already have the information they can give me.
Can someone advise on a strategy or a tool to narrow the problem down ?
The problematic AJAX function submits form data, the working two don't. Forms have a default action which takes place when the form is submitted: post a request with the form data. I failed to prevent this default action.
So the spurious request did indeed come out of the dark underwood of the browser, there is no code in my js files that sends it.
Solution:
YAHOO.util.Event.preventDefault(event);
at the beginning of the form submit event handler.
See also http://developer.yahoo.com/yui/examples/event/eventsimple.html