uShop English (U.S.) for 179!

uStorekeeper English (U.S.) for 149!

 Products
       uTest
       uReserve
       uShop
       uStorekeeper
       uGolf
       uDirectory
       uSignIn
 Tech Support
       Support Policy
       Knowledge Base
            uTest
            uReserve
            uShop
            uStorekeeper
            uGolf
            uDirectory
            uSignIn
       Documentation
       Reference Sites
 Legal
       Software Piracy
       Legal Notices
       Privacy Policy
       Licensing
 Miscellaneous
       Reseller Info
       Contact Us
       Site Map
Problems with image upload

Knowledge Base Lobby : uStorekeeper Support Conference : Configuration Questions
Dec-15-17 11:10 AM EST
Original Message
Problems with image upload
Author Jeffrey Knodel on 11-12-2002 at 22:03 (EST)
I am having problems with a new install of Ustorekeeper on an NT server. The images directory seems to be correctly configured - as it properly propigates the contents of the directory, and allows the deletion of image files, however, when the owner of the site attempts to upload an image, the site simply returns to the password prompt without an error, and the image is not uploaded.

thanks
jk
E-MAIL AUTHOR | TABLE OF CONTENTS

Table Of Contents
  RE: Problems with image upload Bill Weiner, 2002-11-13 06:41:06 (1)
            "RE: Problems with image upload" Jeffrey H. Knodel, 2002-11-13 21:02:00 (2)
            "RE: Problems with image upload" Mark Colasante, 2002-11-13 21:40:08 (3)
                 RE: Problems with image upload Bill Weiner, 2002-11-14 05:30:54 (4)
                      "RE: Problems with image upload" Mark Colasante, 2002-11-18 01:01:01 (5)
                           RE: Problems with image upload Bill Weiner, 2002-11-18 06:23:49 (6)

Messages In This Discussion
         1. RE: Problems with image upload
        Author Bill Weiner on 11-13-2002 at 06:41 (EST)
Hmmmmm... So the Image Manager form comes up ok, and the "Delete Image From Server" option works ok, but yet the "Upload Image To Server" option is just returning the storeowner to uStorekeeper Login Prompt?

That indicates to me that the script is most likely configured correctly and that the directory paths and permissions are also most likely configured correctly.

What it sounds like the to me is that there may be a timing out problem.

As a test, try uploading a small image (1 - 2 Kbytes) and let me know the results.
TABLE OF CONTENTS
                 2. "RE: Problems with image upload"
                Author Jeffrey H. Knodel on 11-13-2002 at 21:02 (EST)
Your understanding is correct. I can ftp images into the images directory and delete them through the image manager interface.

The only files that I have tried to upload are < 1 kb. The webserver comes immediatly back with the password screen.

The ISP has informed me that the webserver is IIS on Win2K. I seem to remember that Apache needs to be configured to allow file uploads. Is there an equivalant configuration for IIS?

jk
TABLE OF CONTENTS
                 3. "RE: Problems with image upload"
                Author Mark Colasante on 11-13-2002 at 21:40 (EST)
I am the network administrator for the site where Jeff Knodel uses your application. I have looked at the Perl scripts that are processing the image upload function, as well as looked at the configuration settings and path directives. I cannot see any misconfigurations, but, I am not exactly sure if I am looking to the right potential solutions. I have also been looking at directory permissions, which appear to be correct. The anonynous IIS user has the appropriate access to the images directory.

Can you explain to me how your application goes about writing the file and saving it to the server? Is it via an ftp process or something else?
TABLE OF CONTENTS
                         4. RE: Problems with image upload
                        Author Bill Weiner on 11-14-2002 at 05:30 (EST)
The Image Manager's "Upload" Feature uses a standard HTML "FILE" type form element to allow the user to select the image that is to be uploaded and POSTs that data with an ENCTYPE of "multipart/form-data" to the CGI script. The HTML is similar to this:

< FORM ACTION="https://www.yourdomain.com/cgi-bin/ustorekeeper-manager.pl" ENCTYPE="multipart/form-data" METHOD="POST" >
< INPUT TYPE="hidden" NAME="password" VALUE="yourpassword" >
< INPUT TYPE="hidden" NAME="command" VALUE="upload_image" >
< INPUT TYPE=FILE NAME=UPLOAD_DATA SIZE=30 >
< INPUT TYPE="SUBMIT" VALUE="Upload Image To Server" >
< /FORM >

(NOTE the ENCTYPE="multipart/form-data" .... as that might be related to the problem.)

Once that data is POSTed to the CGI script, the "parse_form_data" subroutine in the ustorekeeper-lib.pl file detects the "CONTENT_TYPE" as "multipart/form-data", reads the data from stdin, and saves it to a file.

The fact that the storeowner is getting the uStorekeeper Login Screen when trying to upload an image, indicates that the "password" field (and probably the others form fields) are not being detected/received properly from stdin. (The uStorekeeper Script will show the login-screen whenever data is POSTed to it with an invalid or missing "password").

The fact that no file at all is being written to the server, indicates that not even the file data is being detected/received properly from stdin.

So perhaps it is all related to the web server's ability to handle "multipart/form-data".
TABLE OF CONTENTS
                                 5. "RE: Problems with image upload"
                                Author Mark Colasante on 11-18-2002 at 01:01 (EST)
You are correct in saying that ISS cannot handle multipart/form-data, at least not without a 3rd party object to do this. However, your code would have to instantiate that object in order to make an upload process work. This issue must have come up previously for you. What is your suggestion for a workaround?
TABLE OF CONTENTS
                                         6. RE: Problems with image upload
                                        Author Bill Weiner on 11-18-2002 at 06:23 (EST)
I remember a similar problem that someone was having with an Apache server, but it turned out to be their mod_apache library. I don't think that will help you.

For a different product, I remember someone running into a problem where an Internet Explorer browser didn't (or did, I can't remember) include the full file directory path in the file name that get's past to the script with multipart/form-data.... which is really not an issue with uStorekeeper, but you may want to try using a different browser to upload images. Maybe Netscape will work.

Otherwise, it is strange to hear that IIS doesn't handle multipart/form-data and/or that it can be resolved on the script side of things. Really all the script does when it detects CONTENT_TYPE of mutlipart/form-data is read the data from STDIN and parse it accordingly. If the multipart/form-data is not being passed, then it seems like that would have to be handled external to the script (ie. Browser/Server communication). It would also be interesting to see what actually is being passed to the script via something like this in the parse_form_data subroutine:

$content_type = $ENV{'CONTENT_TYPE'};
if ($content_type =~ /^multipart/form-data/)
{
# Read in all data.
read(STDIN, $query_string, $ENV{'CONTENT_LENGTH'});

print "Content-type: text/htmlnn";
print "< HTML >< HEAD >< TITLE > Test < /TITLE >< /HEAD >";
print "< BODY >"
print "< PRE >";
print "The data received is:< BR >";
print $query_string;
print "< /PRE >";
print "< /BODY >< /HTML >";
exit;
}

But again, you may first want to try the upload with a different browser (maybe Netscape) and see if that makes a difference.

Or if you want to really see/verify what data get's passed from the HTML form/Browser to the server's STDIN, then you could try adding the above test code to the ustorekeeper-lib.pl parse_form_data subroutine.

Otherwise, for whatever "object" that you mention needs to be implemented by the script, then you could try adding it to the ustorekeeper-manager.pl "create_image_file_form" or "upload" subroutines... depending on what the object actually does.
TABLE OF CONTENTS

© 2003 Microburst Technologies, Inc.