We're running into the following issue when attempting to work with content in the backend:
Bad Request - Request Too Long
HTTP Error 400. The size of the request headers is too long.
The scenario is that we have a piece of content which has a Multiple Media Picker and there is a lot of associated media - think a type of paint, and all the colours that it might come in.
This then triggers off a request to /umbraco/backoffice/UmbracoApi/Entity/GetByIds?ids=1&ids=2....
Which works up until a threshold and then fails when we have too much associated media.
We can raise these thresholds via tweaks in the web.config up to a certain point. However they only go so far, and eventually the request is blocked by HTTP.SYS , and it would require changes to the registry to work around (which we cannot do on the production machine).
It seems the MNTP uses the same format, so that isn't an option either.
Upon checking the source code, it seems that these Ids are model bound from the Uri from a GET request, indicating that we couldn't build our own control issuing POST's with the required ids in the body.
Pretty much stumped on how to work around this one?
I've left the office for the day, but there were generated from an automated import process. There may be 300-350 different entities? Could be a boatload more....
I've already had to modify the data type to use ntext as opposed to nvarchar as we hit the limit of that sql data type.
Unfortunately this doesn't go far enough. You can still hit an increased limit set in the web.config file and you can only go so far until you hit the limit imposed by HTTP.SYS, which cannot be overridden in web.config (only via changes to the registry).
OK, our bandaid solution for now, was to copy the existing media picker controls that exist in the core out into our own package. We then modified the Javascript to split the requests up into multiple calls. E.g:
var chunks = [];
var chunkSize = 10;
for (var i=0; i<ids.length; i+=chunkSize) {
var chunk = ids.slice(i, i + chunkSize);
chunks.push(chunk);
}
chunks.forEach(function (chunkOfIds) {
entityResource.getByIds(chunkOfIds, "Media").then(function (medias) {
_.each(medias, function (media, i) {
//only show non-trashed items
if (media.parentId >= -1) {
if (!media.thumbnail) {
media.thumbnail = mediaHelper.resolveFileFromEntity(media, true);
}
$scope.images.push(media);
$scope.ids.push(media.id);
}
});
$scope.sync();
});
})
Bad Request - Request Too Long
We're running into the following issue when attempting to work with content in the backend:
The scenario is that we have a piece of content which has a Multiple Media Picker and there is a lot of associated media - think a type of paint, and all the colours that it might come in.
This then triggers off a request to
/umbraco/backoffice/UmbracoApi/Entity/GetByIds?ids=1&ids=2....
Which works up until a threshold and then fails when we have too much associated media.
We can raise these thresholds via tweaks in the
web.config
up to a certain point. However they only go so far, and eventually the request is blocked byHTTP.SYS
, and it would require changes to the registry to work around (which we cannot do on the production machine).It seems the
MNTP
uses the same format, so that isn't an option either.Upon checking the source code, it seems that these Ids are model bound from the
Uri
from aGET
request, indicating that we couldn't build our own control issuingPOST
's with the required ids in the body.Pretty much stumped on how to work around this one?
Hi Chad,
How many items do you assign to the Multiple Media Picker ? Would like to reproduce it.
Dave
I've left the office for the day, but there were generated from an automated import process. There may be 300-350 different entities? Could be a boatload more....
I've already had to modify the data type to use
ntext
as opposed tonvarchar
as we hit the limit of that sql data type.OK, on further checking. We're looking at 1543 media items.
You can configure this in the web.config:
requestLimits maxQueryString="32768"
Unfortunately this doesn't go far enough. You can still hit an increased limit set in the web.config file and you can only go so far until you hit the limit imposed by HTTP.SYS, which cannot be overridden in web.config (only via changes to the registry).
OK, our bandaid solution for now, was to copy the existing media picker controls that exist in the core out into our own package. We then modified the Javascript to split the requests up into multiple calls. E.g:
is working on a reply...