Jump to content

PHP File Upload not working specifically in Firefox with .txt .html upoads???


Recommended Posts

very weird problem and unusually Firefox is having issues with it.

I have a simple upload files form. When I press submit to upload files that are of .txt .html (and who knows what other file types), it hangs saying in the tab text: 'Loading...' and in browser status area: 'Waiting for mysite.com...'

Anyway know a possible reason why? I assume Firefox tries to upload it with a certain encoding that php5 on my IIS server can't interpret?

so this is a windows to windows upload, not sure if binary etc have anything to do with this.


Edit: I should say about 75% of the time a .txt or .html file upload, after repeated testing, sometimes it will go through.
Other filetypes like pdf, xsl, doc go through 100% of the time quickly.
yeh it always works in IE with no problem.

theoretically its not my code (i have used basic php.net upload code from their website with same result)... Since its not refreshing the page (all my form elements and values i entered are still there and its just trying to get past that page), Its still sending (or trying to send) the files over is what I am assuming with that POST info.

I might mess with Ethereal tomorrow and see if the packets are going over to that server. Cause it seems like its not sending anything over.
heres the form:
again standard php I think...

I am going to look at network packets in Ethereal analyzer later today and let you know if anything unusual shows up (going to be my 1st time using that program to debug so keeping my fingers crossed its not too difficult identifying funky network errors).

[code]<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>TEST</title>
</head>

<body>
<?php
if( isset($_POST['submitForm']) )
{
echo "SUBMITTING<br/>" ;

foreach ($_FILES["filename"]["error"] as $key => $error)
{
if ($error == UPLOAD_ERR_OK)
{
$uploaddir = $_SERVER['DOCUMENT_ROOT'].'\\ArianTest\\uploads\\';

$tmp_name = $_FILES["filename"]["tmp_name"][$key];
$name = $_FILES["filename"]["name"][$key];
move_uploaded_file($tmp_name, "$uploaddir/$name");
echo "tmp_name=$tmp_name, name=$name, type=$type, size=$size<br/>" ;
}
}


}//submitted

?>

<form name="upload" method="post" enctype="multipart/form-data" action="<?php echo $_SERVER['PHP_SELF'];?>">

File to upload: <br/>
<input type="file" name="filename[]" value="Upload1" />
<br/>
<input type="file" name="filename[]" value="Upload2" />
<br/>

<br/>
<input type="submit" name="submitForm" value="Submit" />

</form>

</body>
</html>[/code]
Ethereal definately shows some differences. FF doesnt have too many TCP packets after posting form,
IE is more packets/more communication with the intranet server.

Seems like IIS authenticates IE and doesnt for FF.
For example, i found out a few months ago on our corporate intranet, when i goto http://intranet, i noticed IE knows who you are, the person who logged into Windows so you can access intranet pages immediately.
FF doesnt (it asks you for your windows domain logon password every time you visit an intranet page), so you have to go into about:config and set network.automatic-ntlm-auth.trusted-uris to intranet so FF trusts intranet and gives out authenication info to server (at least thats what i think goes on with this setting).

The FF TCP packet stream shows FF must not provide some authentication? in this specific case of uploading files to temp folder on server maybe?...
not sure how to fix, but getting closer to knowing whats causing problem:

http://arihoj.freehostia.com/
In there is the TCP Stream.txt which shows HTTP/1.1 401 Access Denied from IIS
(and the FF and IE capture files. you can view those if you have Ethereal packet analyzer and are better and analzying data like that).

Any Help would be appreciated
Try this....

In Firefox, get the config on the screen by typing [color=green]about:config[/color] in the addressbar, then scroll down to the value labelled [b]network.automatic-ntlm-auth.trusted-uris[/b], double click it and add your intranet address in there.

Restart Firefox (Not sure if this is required, but better safe than sorry).

Let me know if this works.

Regards
Rich
hey HuggieBear,
when I said I found about that problem a few months ago, I meant I already had that value in my about:config for a few months now. So, I already had intranet in there.

so new info,
looked at the http headers:


BOTH FF AND IE on the GET Request seem to work on the troublesome page (so when i land on the upload.php page it knows who i am  in both browsers)
IE
GET /blahFOlder/upload.php HTTP/1.1 NTLMSSP_AUTH, User: ASH\ach
FF
GET /blahFOlder/upload.php HTTP/1.1 NTLMSSP_AUTH, User: \ach


When POSTing to upload the files on this troublesome page (FF seems to forget?):
IE
POST /blahFOlder/upload.php HTTP/1.1 NTLMSSP_AUTH, User: ASH\ach
FF
POST /blahFOlder/upload.php HTTP/1.1 NTLMSSP_AUTH                [NO USER INFO on POST?]


ON a regular php POST page on my intranet that works in both browsers( since it uses no file uploading),
you can see FF knows who i am, (username: ach):
IE
POST /blahFOlder/edit_info.php?user=12 HTTP/1.1 NTLMSSP_AUTH, User: ASH\ach (application/x-www-form-urlencoded)
FF
POST /blahFOlder/edit_info.php?user=12 HTTP/1.1 NTLMSSP_AUTH, User: \ach (application/x-www-form-urlencoded)
This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.