locked
HttpHandler with URLRewriting on dynamic JPG (can no longer serve static jpgs) RRS feed

  • Question

  • User-53430472 posted

    Hi,

    I've setup my web application and server (windows 2003 / ii6) to be able to handle dynamic JPG's and my dynamic JPG's are working great.  However my static JPG's are no longer working.  It serves a dead page ("Page not found")

    The path I am testing is "domain.com/images/examples/50.jpg"  

    As far as I can see, this path should still serve the static JPG as it should not be intercepted by other the handler or the rewrite rules.

    I added a mapping in IIS to the .jpg extension, mapped to c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll

    I have a HttpHandler setup on my JPG's with a wildcard like below. 

    <add verb="*" path="pics/masterPic1.jpg" type="123.JPG_Handler" />


    I also have the following ReWrite rule setup

    <RewriterRule>

    <LookFor>~/pics/(\d+).jpg</LookFor>

    <SendTo>~/pics/masterPic1.jpg?picID=$1</SendTo>

    </RewriterRule>

    Does anyone have an idea what the problem could be?  Even stranger I can get this working on my development IIS5 box, but not my live IIS6 box.  As far as I can tell all the settings are exactly the same. 

     Any help much appreciated.

    Thanks!

    mike123

     

     

     

     
    
     
    Friday, January 26, 2007 10:52 AM

All replies

  • User-627724879 posted

    You will have to map the jpg Mime Type through the ASP.NET runtime in IIS. You will also need to tell IIS not to require the physical file to exist.

     First mapping images through ASP.NET:

    1. Open the IIS admin tool

    2. Open the Properties of your web site

    3. Select the Home Directory Tab of the Admin dialog

    4. Click the Configuration button

    5. Click Add, the Add/Edit application extension dialog will appear.

    6. Enter 'c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll' (this would be a typical path yours may vary) to the executable field.

    7. Enter .jpg in the Extension field.

    8. You can limit the verbs to GET,HEAD,POST,DEBUG or just select all.

    9. Uncheck 'Verify that File Exists'.

    10. Click OK until you have closed everything.

    11. Rinse and Repeat as nessecary for other file extensions.

    I think this will help you out.

     

    Saturday, January 27, 2007 1:52 PM
  • User-53430472 posted

    Hi Chris,

    Thanks for the reply, but I think you misread my post.  I posted that I have done that part already and I am succesfully serving dynamic JPG's.  The problem is that I can no longer serve static JPG's.  I am not sure exactly what is causing this.  Any idea?

    Thanks again,

    Mike123

    Monday, January 29, 2007 6:12 AM
  • User-627724879 posted
    I don't think I misread your post. I and many other experienced this same issue when DotNetNuke 2.x was first released. I tried to find some of those old references, but came up a little short. I know the answer is somewhere in those threads of thought from 2 years ago. If you do a view source can you see how your images are referenced? Can you create a full path in the browser, http://www.mysite.com/images/mystatic.jpg, and see the image? Check your IIS log to see what the actual status code is. These are all things I did back then to figure out the problem.
    Monday, January 29, 2007 2:55 PM
  • User-53430472 posted

     

    Hey Chris,

    When I manually type in the URL, the file does not serve.

    2007-01-29 20:46:45 65.17.224.4 GET /Images/600x300/192.jpg - 80 - 10.255.255.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+.NET+CLR+2.0.50727;+.NET+CLR+1.1.4322) 200 0 0

    Here is the IIS log file.  I'm thinking maybe my rewrite rules are causing this , or my httphandler rules.. However as I have displayed them I don't see how they could be causing problems.

    The file definatley isn't serving.


    Any input much appreciated!!

    Thanks :)

    mike123

     

     

    Monday, January 29, 2007 4:21 PM
  • User-627724879 posted
    The 200 status code is a good code, meaning it should have been served. So now to look at teh handler.
    Monday, January 29, 2007 9:24 PM
  • User113421904 posted

    2007-01-29 20:46:45 65.17.224.4 GET /Images/600x300/192.jpg - 80 - 10.255.255.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+.NET+CLR+2.0.50727;+.NET+CLR+1.1.4322) 200 0 0

    200 means HTTP OK.

    I think one straight forward method to test this is open the image directly in your browser.

    e.g.

    http://localhost/Images/600x300/192.jpg

    http://65.17.224.4/Images/600x300/192.jpg

    Tuesday, January 30, 2007 1:33 AM
  • User-53430472 posted

     

    Can anyone see anything wrong with my  handler?  It seems to be catching requests that I don't want it to and succesfully serving JPG's (which isnt really succesful since its serving them as empty streams i believe)

     

    Thanks once again

    mike123

    Tuesday, January 30, 2007 8:08 AM
  • User113421904 posted

    Try this: 

    <add verb="*" path="pics/*.jpg" type="123.JPG_Handler" />

    also you can try change the relative path to abosulte path from the web application root folder.

     instead of:

    <add verb="*" path="pics/masterPic1.jpg" type="123.JPG_Handler" />


     

    Wednesday, January 31, 2007 4:17 AM
  • User-53430472 posted

    Hi Zhao Ji Ma,

    I tired that but no luck.  I'm not sure how I would write the absolute path? 

    Also one thing is I can get it working on my development machine (ii5 windows 2000) but not on my live server (windows 2003 iis6)

     Any other suggestions very much appreciated!! :)

     

    thanks again,

    mike123

    Wednesday, January 31, 2007 6:37 AM