Hi Michael, On 06/01/2025 17:28, Michael Tremer wrote: > Hello Adolf, > > I assume this might not fully fix the problem since we don’t know for certain if the uploaded file is a JPEG file. I am sorry, I had intended to put something about that into the commit but I forgot to do it. I had various image files which I could check the type of and I found a jpg, a png and a tiff image file. I uploaded each of these in turn and the same image/jpeg content type successfully displayed the uploaded image onto the browser screen. > > I believe this is why have chosen something very generic instead of a specific image type. I assume that we would have to run something to check the correct MIME type of the file before we can send anything. Of course it might be that how I have done it works for now for any (most/some) image files but it could also change in the future. > > https://metacpan.org/release/FITZNER/File-LibMagic-0.96/view/LibMagic.pm > > This could do the job. I can have a look at that link and modify the code if you would prefer that. In the wiki we explicitly say jpg or png only, although as I said I was able to successfully upload a tiff image file and it was displayed. We can maybe discuss further in the conf call to finalise on what I should do. Regards, Adolf. > > -Michael > >> On 6 Jan 2025, at 16:21, Adolf Belka wrote: >> >> - Something changed in some package in CU188 that means that the existing method of >> printing the content type to the browser no longer worked. >> - I tested it in some stand alone code and even if using text/txt for the content-type >> print statement the File::Copy::copy then resulted in an Internal Server Error with >> the same message as with the image file which was "malformed header from script >> 'logo.cgi': Bad header:". >> - I tested it with text, html, image and application. In all cases the error message >> about a bad header was provided. >> - Did some searching and found an alternative way to explicitly print the header info >> which is what I have used in this patch change. >> - With this approach, in the stand alone code, I was able to get an image, html code or >> text shown in the browser correctly and without any error message. >> - I then used this new method in the logo.cgi code as submitted here and tested the >> change in my vm testbed and the image was shown in the captive portal correctly. >> - So this change fixes the problem with the logo not being shown but I have been unable >> to identify what changed to stop the method that worked prior to CU188 from working >> any more. >> >> Fixes: Bug13795 >> Tested-by: Adolf Belka >> Signed-off-by: Adolf Belka >> --- >> html/cgi-bin/captive/logo.cgi | 9 +++++---- >> 1 file changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/html/cgi-bin/captive/logo.cgi b/html/cgi-bin/captive/logo.cgi >> index 8f292b171..09fe784b8 100644 >> --- a/html/cgi-bin/captive/logo.cgi >> +++ b/html/cgi-bin/captive/logo.cgi >> @@ -2,9 +2,9 @@ >> ############################################################################### >> # # >> # IPFire.org - A linux based firewall # >> -# Copyright (C) 2016 Alexander Marx alexander.marx(a)ipfire.org # >> +# Copyright (C) 2016-2024 IPFire Team # >> # # >> -# This program is free software you can redistribute it and/or modify # >> +# This program is free software: you can redistribute it and/or modify # >> # it under the terms of the GNU General Public License as published by # >> # the Free Software Foundation, either version 3 of the License, or # >> # (at your option) any later version. # >> @@ -29,6 +29,7 @@ use File::Copy; >> >> require '/var/ipfire/general-functions.pl'; >> >> +my $q = new CGI; >> my $logo = "${General::swroot}/captive/logo.dat"; >> >> # Send 404 if logo was not uploaded and exit >> @@ -37,8 +38,8 @@ if (!-e $logo) { >> exit(0); >> } >> >> -print "Content-Type: application/octet-stream\n\n"; >> - >> # Send image data >> +print $q->header(-type=>"image/jpeg"); >> +binmode STDOUT; >> File::Copy::copy $logo, \*STDOUT; >> exit(0); >> -- >> 2.47.1 >> > -- Sent from my laptop