I have just plugged iJento into my project to track marketing data and there is this track method that tracks data entered on a form.
All forms are okay except one rather big form that gives out: HTTP Error 400 - The size of the request headers is too long.
The cookie in the header is indeed pretty big on that form but I don't want to disable it.
I tried enlarging the header size on IIS7. I went to "Request Filtering" and added a new Header of type "Cookie" whose size is a lot larger than it needs to be but that didn't solve it.
Is there another way to circumvent the problem?
Found the answer.
Going to the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters
and added two new DWORD (32bit) values MaxFieldLength and MaxRequestBytes
They need to be set to something larger than the defaults, in my case I used the maximum allowed values which are 65534 and 16777216 in Hexadecimal.
Then you need to restart he computer and voila.. problem solved.
Related
I was playing with Postman Flows, and I was trying to learn by using the Trello API. All requests work on their own if executed manually. I've also debugged values using the terminal to understand where the problem lies. Before that, here's a summary of what I'm doing.
Get all boards for a given trello workspace
For each board, delete that board.
The complete flow looks like this:
I've checked that on the last block Send Request, the looped value of /variable/id outputs the proper board id. I've done this by checking with a terminal block and a string block. I started suspecting that this is caused by a failure of Postman to understand that the variable I'm trying to use is a path variable and not a query parameter. As such I tried to pass a static value to the Send Request and it 404'ed as well (tech aside: in theory for n ids it should give me one 200 and n-1 404s since the variable is static and the board would not be able to be deleted multiple times).
My suspicion comes from the fact that when configuring the block for this request:
You do not get prompted to add the board variable. I've tried to type it in anyway, and even use combinations like :board, with no avail. In fact like I said above, if I use these variables with static values, it still 404s.
ignore the parsing message on the right hand side...
As you can see, board doesn't show up. Did I end up hitting a bug, or is this user error? One thing I do not know how to do, but would help clarify that the issue is that a null value is being passed on to the DELETE would be to output the request itself. On a terminal block I can only see the response.
Thanks in advance.
UPDATE:
After checking the Postman console on the app, I've noticed that in fact the path variable being used is whatever is set on the collection request. It's like it takes the URL as a static field and disregards the path variables. Any thoughts?
Path variables won't be available in your Send Request. Instead, define your path variable with an environment/collection/global variable (i.e. {{board}}) in the value of the path variable. Then it will show up the relevant block of your flow.
I've recently been using libcurl to detect when a particular web page has been updated by listening for a change in the page's HTTPS status code by employing CURLINFO_RESPONSE_CODE.
However, I am attempting to retrieve newly uploaded data from a different webpage now, but its HTTPS status code stays the same at 200 even when the page has been updated with new information.
As such, are there any other parameters that can be monitored to notify as quickly as possible that there has been a change in the content of a page? Initially, I thought about counting the number of bytes in the page when it's returned via my libcurl function, and then checking if the next response's byte length is different (hence, signalling that some new content has been added to the page).
This is a time-sensitive application however, and this method of counting the number of bytes and making a comparison for every request-response may not be the best approach in terms of latency, and also may not be particularly accurate (e.g. maybe an aspect in the header such as a "hit/miss from cloudfront" could result in a different page length size, even though there isn't any new front-end content uploaded).
Summary question:
Are there any parameters (perhaps in the response header?) other than the HTTPS status code that can be monitored with libcurl to check if a page has been updated with any new content, as quickly as possible?
I have a rather long form (1000 checkboxes) that the customer goes through to order.
But I get the following error when it goes over a certain limit (100 items):
Failed to add HTML header.ColdFusion was unable to add the header you
specified to the output stream. This is probably because you have
already used a cfflush tag in your template or buffered output is
turned off
Q: Is that an IIS setting or a ColdFusion administrator setting?
I did some research before posting this question, and it doesn't have to do with AJAX and debug settings. All debug settings are turned off and I get the error on form submit.
Does your form POST or GET? If it's a GET you may be maxing out the URL length limit. If it's a POST, then you are probably running into the limit in CF on the number of form fields. This article details how to modify the value.
You may want to consider other ways of sending that data to the server. Perhaps using jQuery to serialise the form and send the JSON as a single parameter?
Sounds very similar to an error we had after moving a site with a large number of fields to a new environment. our error read a bit different but you could be getting a different error depending on what you're doing.
500
ROOT CAUSE:
coldfusion.filter.FormScope$PostParametersLimitExceededException: POST
parameters exceeds the maximum limit specified in the server.
There is a coldfusion setting in your runtime.xml file you could try changing or removing:
<var name='postParametersLimit'><number>100.0</number></var>
I have a strange problem with Google Charts API.
According to the docs, the "GET" limit is 2048 bytes, but I have this one link I created that is well below the limit (1663 bytes) and still chokes the server with a "Request-URI Too Large" error.
Here's the link (check "view source"): broken chart
I'm guessing that it's not really a size problem, but rather some kind of parsing problem in the Google Chart API..?
I have implemented the "form" fallback (to enable 16K requests), but I only want to use this method when the request gets bigger than the allowable 2K.
Any ideas?
Thanks,
Sebastian
Maybe lose the 1-300 chxl parameter - it doesn't display well at all. And check your chof=validate. I'm not sure what it does but if I remove both of those things your chart appears perfectly.
Simplified code example: http://pastebin.com/9ZQxSXi9
Hi
I wanted to experiment with the restlet 2.0 library and the gpodder webservice but somehow i reached a point where I can't see the wood for the trees.
The service in the example requires HTTP authentication and to post some JSON content to a URL.
Nothing that complicated but somehow even though the debug view claims the request object to contain the necessary content the RESTful webservice's response leads me to believe the HTTP header of the request was missing the content.
Any ideas on what's the reason? Thanks in advance.
The problem is that that none of the implementation of WriterRepresentation I've seen (JsonRepresentation, JacksonRepresentation, XStreamRepresentation) set the size of the representation when an object is passed. So if you create a new JacksonRepresentation(map) the size is not calculated.
You have to compute manually the length of the map content and calling Representation.setSize().
Or, as I did, use a
new JsonRepresentation(" a json string... ");
This constructor is able to compute the size, of course, that's the string length, so the proper content-length header is set and everything works smooth.