If I use ImageGen to generate images recursively, I get a 404 HTTP response header, as well as an image. Chrome handles this very strangely (sometimes it renders the image, and sometimes it doesn't). Here's an example URL:
Note that I am running the primary site on localhost, but the nested image is on a real looking domain (actually just localhost configured in the hosts file to use a domain name). This is because I was unable to add localhost with the port number to the domain whitelist in ImageGen.config (probably another ImageGen bug).
If you are curious why I was doing this, I was trying to first proportionally resize an image to a set width, and then crop the image to only show a set height. The inner image does the resize and the outer image does the crop.
Also, it seems like sometimes when I inspect the response to the images that return a 404, the content is text (rather than an image) that says "An error occurred while parsing EntityName. Line 1, position 117.".
If this is referring to the URL I posted above, keep in mind that I modified the URL somewhat to remove some sensitive information, so that character position wouldn't be exact.
This is really the long way around the challenge you face :)
While there may be a bug here let's start with trying to solve your issue first and I'll look into the potential return code problem afterward.
If I understand correctly, you have a large image and want to resize it to a specific width and height. The width should show the entire image and the height will trim off any excess required to make the image the desired height.
Let's take it step by step and you'll see how this can be done.
Assume I have large, landscape image (that is, a photo that is wider than it is tall) named landscape.jpg and I want to create a final image that is 400px wide but only 100px tall, taking the center of the image for the crop area. I'd do this:
If I had a specific area to crop from (because you'd used Umbraco's built-in image cropper data type for instance) you have the coordinates of the selected crop area already and only need to specify the width and/or height of the resized image:
Wow, it seems I misunderstood some of the parameters and this one works just fine for me: /ImageGen.ashx?image=/test.jpg&quality=100&width=100&height=50&crop=resize&valign=top
Thanks!
By the way, I'd say that encoding issue may be a bug and the inability to add an IP address or localhost (with or without a port) to the domain whitelist are deficiencies that should be addressed.
Sorry, I spoke too soon. I'm still having an issue. If the height is less than the specified height, it seems that the height will actually be increased and the right of the image will be lopped off, which is not what I want to happen.
Here's what I'm trying to do:
First, resize the image to a specified width. This should be a proportional resize (i.e., the height will change appropriately). It should allow upscaling.
Second, remove any part of the image that extends beyond a specified height. If the image is shorter than the specified height (after the resize in the previous step), then the height should not be changed.
As an example, suppose I have an image that is 100x200. I want to resize it to 1000x100. Following the above steps, this would happen:
The image would be resized to be 1000x2000.
That image would then be cropped to be 1000x100 (the bottom 1900 pixels would be removed).
That seems to work fine. However, this second example doesn't. Suppose I have an image that is 1000x200. I want to resize it to 100x100. Following the above steps, this would happen:
The image would be resized to be 100x20.
The image would not be cropped (because the height is less than 100), so it would remain at a size of 100x20.
However, that second part does not happen. It seems to first resize the image to 500x100, then crops the right off so it's 100x100.
To test this, you can use a 1000x200 image with this ImageGen path: /ImageGen.ashx?image=/1000x200.png&quality=100&width=100&height=100&crop=resize&valign=top
You asked ImageGen for an image with dimensions of 100x100... you get an image that is 100x100. To do that, ImageGen will put as much of the source image in the resized image as possible, cropping off any excess to make it the requested size upon completion. That's just how it works. ImageGen doesn't do multiple resizing passes, which would waste cpu and memory. Instead, the final size is calculated and a single resize is performed.
I'll check on the domain whitelist but it should allow both localhost and ip numbers. If not that's a bug on my part. Port numbers are not supported.
Any word on if the localhost/ip addresses not working in the domain whitelist is in fact a bug?
Also, I'm not sure what you mean when you say you don't support port numbers. I'm thinking that you mean you don't discriminate based on port numbers (so, if I whitelisted localhost, it would work regardless of if I set the port to 80 or 1234 or anything else). If so, that makes sense to me.
By the way, I just described the transform I was trying to do as if it were multiple passes, because it is easier to understand the concept that way. It could be done in a single pass from a programming perspective (no extra CPU or memory required). Though, I understand if you don't want to support more advanced transforms like this, so long as they are possible using recursive transforms (which, if the bugs are fixed, should be).
I'm testing an ImageGen request of a remote ImageGen request along the lines of your original post. I've often called remote services but have found that attempting to pass in a querystring parameter while within another querystring causes problems... at best you can send in one parameter and for maximum reliability should be the last parameter because anything following the & character in a querystring will go to the original request.
An example would be helpful. Suppose I have an image server at img.example.com and it needs an id parameter to return the appropriate image. The request to this remote site might be http://img.example.com/server.aspx?id=5555.
Let's further suppose we want to have ImageGen resize that remote image. We'd make this request
You might think the &width=400 would be passed along to the server.aspx process, but it isn't. It goes with the imagegen.ashx request. The only thing passed into the image= querystring parameter is http://img.example.com/server.aspx?id=5555. That's just the way querystrings work.
Which means you won't be successful with your original attempt because you want to pass multiple parameters to the remote request.
For years now I've thought there was no way around this but today it occurred to me that it might be possible if the remote request were URL encoded. It turns out that's possible! At least on my servers and with my browsers. I wouldn't want to say categorically it will work without many more tests with a much broader range of desktop, tablet, and mobile browsers and different versions of IIS.
Let's suppose, in our example above, the &width=400 parameter were something I wanted to pass along to the remote process. In my quick tests you could urlencode everything you want to send to the remote request.
Lastly, you're correct that there is a 404 response coming through when ImageGen calls ImageGen. I'll be researching that and will include a fix in the next release.
It seems to be related to url-encoded remote requests with multiple parameters such as:
I'm glad you are figuring things out. FYI, while working with ImageGen, I found it necessary to make some web.config changes. For one, I had to allow double escaping in the request (the allowDoubleEscaping attribute on requestFiltering). Also, I had to change the requestPathInvalidCharacters. I forget if that had to do with recursively using ImageGen, or if it had to do with my workaround, which was to use URL rewriting to avoid ampersands in the URL.
By the way, I found that browsers handled the 404 situation inconsistently. Sometimes they'd show the image, and sometimes they wouldn't. It seems that browsers get confused when they get a 404 response code with a reponse that has otherwise valid image data.
Let me know if I can be of any further assistance. Might be a while until I see any of your replies though... the Umbraco forums apparently have a bug where I am not being sent email notifications when a reply is made.
I believe I've solved all the issues so that you can make requests for ImageGen from within ImageGen requests, using any combination of parameters in either request.
Hopefully the Umbraco forums encode that properly. If not, here's a JSFiddle of the path: http://jsfiddle.net/fYZr6/
I tossed the path into a JavaScript comment, and I put the actual markup I'm using for the image into the HTML (there is extra encoding required when you put the path in the img src attribute).
I'm getting a 404. The ImageGen.ashx?version shows up as: ImageGen Professional version 2.9.2.29484
Some notes. I'm using a port number (Visual Studio does that automatically). Is that OK? Also, I noticed that the URL you showed above as an example isn't fully encoded properly (i.e., it shows "image=http://localhost/imagegen.ashx" rather than "image=http%3A%2F%2Flocalhost%2Fimagegen.ashx").
Yes, that should work. Issues you might have had along the way could include settings in the "default" class in the /config/imagegen.config file not allow upsizing or limiting the maximum size. You may want to alter the settings in the default class, or make new classes for your specific uses, which would also simplify the url.
Your encoding is much cleaner now, too. It should have worked just fine before but it some of it was unnecessary. In fact, you can leave the http://localhost:61659/imagegen.ashx of the 'remote' request unencoded without penalty as far as I've seen (let me know if you find any reason you need to encode it beyond preference). And you definitely don't need to convert & into & in the unencoded parameters, though browsers don't care one way or the other so again it is preference.
FWIW, I have found putting all the 'local' request parameters in first and then encoding all the 'remote' request parameters and placing them at the end makes things easier to read in my tests, rather than when I put the encoded 'remote' request in the middle of unencoded parameters. Like this:
/imagegen.ashx?width=1175&height=425&crop=0,0,1175,425&compression=100&image= (encoded imagegen.ashx request and params go here)
Though that's just my preference and and doesn't alter the behaviour of ImageGen.
Glad this is working now. I'll release 2.9.2 shortly. Thanks again for your help and feedback!
Not sure if you ever got my email (I got an error and attempted to send a second time... Exchange Online can be fickle). Are you still working on an ImageGen 2.9.2 release?
Hi, Nick. No, didn't get your email. Yes, still working on 2.9.2 and the mirroring issue when over-sizing crops. How are you getting on with the pre-release beyond that?
I see that your most recent response in this thread was March 4th and that ImageGen shows as having been updated on April 11th. However, I see that the version is still 2.9.1 (and you were talking about releasing a version 2.9.2). Is that a mistake... does the current version include the fixes we talked about in this thread?
ImageGen Pro 2.9.1.36630 Returns 404 AND Image for Recursive Images
If I use ImageGen to generate images recursively, I get a 404 HTTP response header, as well as an image. Chrome handles this very strangely (sometimes it renders the image, and sometimes it doesn't). Here's an example URL:
http://localhost:12345/ImageGen.ashx?image=http%3A%2F%2Ftest.domain.com%2FImageGen.ashx%3Fimage%3D%252Fmedia%252F1111%252FsomeImage.jpg%26altImage%3D%252Fimages%252FaltImage.png%26width%3D70%26allowupsizing%3Dtrue%26compression%3D100&width=70&crop=0%2C0%2C70%2C50&compression=100
Note that I am running the primary site on localhost, but the nested image is on a real looking domain (actually just localhost configured in the hosts file to use a domain name). This is because I was unable to add localhost with the port number to the domain whitelist in ImageGen.config (probably another ImageGen bug).
If you are curious why I was doing this, I was trying to first proportionally resize an image to a set width, and then crop the image to only show a set height. The inner image does the resize and the outer image does the crop.
Also, it seems like sometimes when I inspect the response to the images that return a 404, the content is text (rather than an image) that says "An error occurred while parsing EntityName. Line 1, position 117.".
If this is referring to the URL I posted above, keep in mind that I modified the URL somewhat to remove some sensitive information, so that character position wouldn't be exact.
Hi, Nicholas,
This is really the long way around the challenge you face :)
While there may be a bug here let's start with trying to solve your issue first and I'll look into the potential return code problem afterward.
If I understand correctly, you have a large image and want to resize it to a specific width and height. The width should show the entire image and the height will trim off any excess required to make the image the desired height.
Let's take it step by step and you'll see how this can be done.
Assume I have large, landscape image (that is, a photo that is wider than it is tall) named landscape.jpg and I want to create a final image that is 400px wide but only 100px tall, taking the center of the image for the crop area. I'd do this:
imagegen.ashx?image=landscape.jpg&width=400&height=100&crop=resize
If I wanted to focus on the top-right corner of the image when cropping (that is, trimming off the bottom and left if needed) I would do this:
imagegen.ashx?image=landscape.jpg&width=400&height=100&crop=resize&align=right&valign=top
If I had a specific area to crop from (because you'd used Umbraco's built-in image cropper data type for instance) you have the coordinates of the selected crop area already and only need to specify the width and/or height of the resized image:
imagegen.ashx?image=landscape.jpg&width=400&height=100&crop=50,100,200,50
Hope this helps.
cheers,
doug.
Wow, it seems I misunderstood some of the parameters and this one works just fine for me: /ImageGen.ashx?image=/test.jpg&quality=100&width=100&height=50&crop=resize&valign=top
Thanks!
By the way, I'd say that encoding issue may be a bug and the inability to add an IP address or localhost (with or without a port) to the domain whitelist are deficiencies that should be addressed.
Sorry, I spoke too soon. I'm still having an issue. If the height is less than the specified height, it seems that the height will actually be increased and the right of the image will be lopped off, which is not what I want to happen.
Here's what I'm trying to do:
Hi, Nicholas,
You asked ImageGen for an image with dimensions of 100x100... you get an image that is 100x100. To do that, ImageGen will put as much of the source image in the resized image as possible, cropping off any excess to make it the requested size upon completion. That's just how it works. ImageGen doesn't do multiple resizing passes, which would waste cpu and memory. Instead, the final size is calculated and a single resize is performed.
I'll check on the domain whitelist but it should allow both localhost and ip numbers. If not that's a bug on my part. Port numbers are not supported.
cheers,
doug.
Any word on if the localhost/ip addresses not working in the domain whitelist is in fact a bug?
Also, I'm not sure what you mean when you say you don't support port numbers. I'm thinking that you mean you don't discriminate based on port numbers (so, if I whitelisted localhost, it would work regardless of if I set the port to 80 or 1234 or anything else). If so, that makes sense to me.
By the way, I just described the transform I was trying to do as if it were multiple passes, because it is easier to understand the concept that way. It could be done in a single pass from a programming perspective (no extra CPU or memory required). Though, I understand if you don't want to support more advanced transforms like this, so long as they are possible using recursive transforms (which, if the bugs are fixed, should be).
Hi, Nicholas,
I've checked on the white listing of remote domains and here's what you need to know:
You must include the fully qualified domain for the remote site.
For security reasons you need to specify the exact domain. Or, you can use the
*wildcard.Port numbers are considered part of the domain and the above two rules apply.
IP numbers can also be used.
Here are some examples:
If the remote image is at http://www.example.com/photo.jpg you'd have
<Domain>www.example.com</Domain>in the config file.If the remote image is at http://example.com/photo.jpg you'd have
<Domain>example.com</Domain>in the config file.If you have remote images at a number of sites at, say, http://farm1.example.com and http://farm2.example.com and http://www.example.com you could enter all three domains in the config file or use a wildcard like this:
<Domain>*.example.com</Domain>.If the remote image is at http://example.com:8080/photo.jpg you'd have
<Domain>example.com:8080</Domain>in the config file.If the remote image is at http://127.0.0.1:8080/photo.jpg you'd have
<Domain>127.0.0.1:8080</Domain>in the config file.cheers,
doug.
Hi, again, Nicholas,
I'm testing an ImageGen request of a remote ImageGen request along the lines of your original post. I've often called remote services but have found that attempting to pass in a querystring parameter while within another querystring causes problems... at best you can send in one parameter and for maximum reliability should be the last parameter because anything following the
&character in a querystring will go to the original request.An example would be helpful. Suppose I have an image server at img.example.com and it needs an
idparameter to return the appropriate image. The request to this remote site might behttp://img.example.com/server.aspx?id=5555.Let's further suppose we want to have ImageGen resize that remote image. We'd make this request
You might think the
&width=400would be passed along to the server.aspx process, but it isn't. It goes with the imagegen.ashx request. The only thing passed into theimage=querystring parameter ishttp://img.example.com/server.aspx?id=5555. That's just the way querystrings work.Which means you won't be successful with your original attempt because you want to pass multiple parameters to the remote request.
For years now I've thought there was no way around this but today it occurred to me that it might be possible if the remote request were URL encoded. It turns out that's possible! At least on my servers and with my browsers. I wouldn't want to say categorically it will work without many more tests with a much broader range of desktop, tablet, and mobile browsers and different versions of IIS.
Let's suppose, in our example above, the
&width=400parameter were something I wanted to pass along to the remote process. In my quick tests you could urlencode everything you want to send to the remote request.becomes
when passed into the
?image=parameter for ImageGen, like so:The
&color=sepiaparameter would be handled by imagegen.ashx while the%26width%3D400would be handled by the remote server prcoess.Which means... with some careful urlencoding you should be able to get the 2-step processing you originally requested.
cheers,
doug.
Lastly, you're correct that there is a 404 response coming through when ImageGen calls ImageGen. I'll be researching that and will include a fix in the next release.
It seems to be related to url-encoded remote requests with multiple parameters such as:
Have you found any other situations that produce this behaviour?
Fortunately, in spite of the error code everything actually works properly and the correct image is displayed.
Thanks for the bug report, Nicholas!
cheers,
doug.
Hi Doug,
I'm glad you are figuring things out. FYI, while working with ImageGen, I found it necessary to make some web.config changes. For one, I had to allow double escaping in the request (the allowDoubleEscaping attribute on requestFiltering). Also, I had to change the requestPathInvalidCharacters. I forget if that had to do with recursively using ImageGen, or if it had to do with my workaround, which was to use URL rewriting to avoid ampersands in the URL.
By the way, I found that browsers handled the 404 situation inconsistently. Sometimes they'd show the image, and sometimes they wouldn't. It seems that browsers get confused when they get a 404 response code with a reponse that has otherwise valid image data.
Let me know if I can be of any further assistance. Might be a while until I see any of your replies though... the Umbraco forums apparently have a bug where I am not being sent email notifications when a reply is made.
-Nick
Hi, Nick,
I believe I've solved all the issues so that you can make requests for ImageGen from within ImageGen requests, using any combination of parameters in either request.
Would be willing to test it before I release it publicly? If so, please send me a note through my website at http://www.percipientstudios.com/about/contact.aspx.
It will now work as you initially expected, provided you url-encode everything in the inner request.
As an example: I have a photo I want to use as a short and wide banner image. First we could resize the image.
imagegen.ashx?image=photo.jpg&width=1000&allowupsizing=true&quality=100Next we'll crop it to show only a horizontal strip 50px from the middle of the resized image.
imagegen.ashx?crop=noresize&height=50&width=1000&image=((urlencoded request from above))The result would be:
imagegen.ashx?crop=noresize&height=50&width=1000&image=http://localhost/imagegen.ashx%3Fimage%3Dphoto.jpg%26width%3D1000%26allowupsizing%3Dtrue%26quality%3D100Use whatever combination of parameters you need to get the effect you want that is more complex than might be achieved with a single call to ImageGen.
cheers,
doug.
Hi Doug,
I sent you a message via your website.
By the way, would this still work if I left out the domain (i.e., if I wanted to do a recursive encoding locally)?
Basically, without the "http://localhost" in your example.
Thanks,
Nick
Thanks, Nick, I'll email it to you for testing shortly.
No, the
http://is what tells ImageGen that the request isn't to be grabbed from the filesystem but from an http request.cheers,
doug.
Hi Doug,
Bad news. Looks like it's not working. For your reference, here's the URL I'm using:
http://localhost:61659/ImageGen.ashx?image=http%3A%2F%2Flocalhost%2FImageGen.ashx%3Fimage%3D%252Fmedia%252F1049%252Fhomepage_1170x425_03.jpg%26altImage%3D%2Fimages%2Fwhite800x600.png%26width%3D1170%26allowupsizing%3Dtrue%26compression%3D100%26nocache%3Dtrue&width=1170&height=425&crop=0%2C0%2C1170%2C425&compression=100
Hopefully the Umbraco forums encode that properly. If not, here's a JSFiddle of the path: http://jsfiddle.net/fYZr6/
I tossed the path into a JavaScript comment, and I put the actual markup I'm using for the image into the HTML (there is extra encoding required when you put the path in the img src attribute).
I'm getting a 404. The ImageGen.ashx?version shows up as: ImageGen Professional version 2.9.2.29484
Some notes. I'm using a port number (Visual Studio does that automatically). Is that OK? Also, I noticed that the URL you showed above as an example isn't fully encoded properly (i.e., it shows "image=http://localhost/imagegen.ashx" rather than "image=http%3A%2F%2Flocalhost%2Fimagegen.ashx").
-Nick
Hi Doug,
After working through a few issues, it appears to be working now! Here's the path that is working for me: http://jsfiddle.net/26sH6/
And here it is in an image tag:
<img src="/ImageGen.ashx?image=http%3A%2F%2Flocalhost%3A61659%2FImageGen.ashx%3Fimage%3D%252Fmedia%252F1058%252Fhomepage_1170x425_01.jpg%26altImage%3D%252Fimages%252Fwhite800x600.png%26width%3D1175%26allowupsizing%3Dtrue%26compression%3D100%26nocache%3Dtrue&width=1175&height=425&crop=0%2C0%2C1175%2C425&compression=100" />
-Nick
Hi, Nick,
Yes, that should work. Issues you might have had along the way could include settings in the "default" class in the
/config/imagegen.configfile not allow upsizing or limiting the maximum size. You may want to alter the settings in the default class, or make new classes for your specific uses, which would also simplify the url.Your encoding is much cleaner now, too. It should have worked just fine before but it some of it was unnecessary. In fact, you can leave the
http://localhost:61659/imagegen.ashxof the 'remote' request unencoded without penalty as far as I've seen (let me know if you find any reason you need to encode it beyond preference). And you definitely don't need to convert & into & in the unencoded parameters, though browsers don't care one way or the other so again it is preference.FWIW, I have found putting all the 'local' request parameters in first and then encoding all the 'remote' request parameters and placing them at the end makes things easier to read in my tests, rather than when I put the encoded 'remote' request in the middle of unencoded parameters. Like this:
/imagegen.ashx?width=1175&height=425&crop=0,0,1175,425&compression=100&image= (encoded imagegen.ashx request and params go here)Though that's just my preference and and doesn't alter the behaviour of ImageGen.
Glad this is working now. I'll release 2.9.2 shortly. Thanks again for your help and feedback!
cheers,
doug.
Hi Doug,
Not sure if you ever got my email (I got an error and attempted to send a second time... Exchange Online can be fickle). Are you still working on an ImageGen 2.9.2 release?
Thanks,
Nick
Hi, Nick. No, didn't get your email. Yes, still working on 2.9.2 and the mirroring issue when over-sizing crops. How are you getting on with the pre-release beyond that?
cheers,
doug.
Hi Doug,
I see that your most recent response in this thread was March 4th and that ImageGen shows as having been updated on April 11th. However, I see that the version is still 2.9.1 (and you were talking about releasing a version 2.9.2). Is that a mistake... does the current version include the fixes we talked about in this thread?
Thanks, Nick
is working on a reply...