One last try... emulating HTTP POST with applet

Question

I am trying emulate the HTTP POST method for file uploading using an applet. More specifically, I am trying to upload raw data to a PHP script by making the PHP script think it is receiving a file when in reality all it is receiving is a series of headers, some other necessary info, the data, and a closer. The PHP is then supposed to save the data into a file.
I have looked at eight or ten threads, explanations, and sample code in this and other forums that deal with this exact same thing, some even specific to PHP, read various documents on and explanations of HTTP headers and so forth, corrected every code error and possible code error I could find, and tried a gazillion variations, but still can't get the PHP script to think that it is receiving a file.
As far as I can tell, communication with the server is being established, the server is receiving info and sending responses back, the PHP script is defrinitely being activated to do its thing, but the PHP is not recognizing anything that looks like a file or even a file name to it.
The following information may be relevant:
The PHP works perfectly with real files uploaded from real HTML pages.
The server uses Apache.
The server has no Java support (shouldn't matter, but otherwise I would be using servlets at that end instead of PHP).
the applet is in a signed jar, and is trying to store information in the same directory that it came from.
I am using the Firefox browser (shouldn't matter?) .
I am hoping that someone knowegeable about this can look at the code below and point our any errors. I've also included the response I get from the server, and the PHP code. If there are no obvious errors, can you think of anything else tthat might be going wrong besides the code itsef?
Please don't suggest I try alternate means of doing this or grab some working code from somewhere. I may very well wind up doing that, but I'm a stubborn bastard and want to find out what the #^%R$($ is going wrong here!!!
Here is the latest incarnation of the applet code: All it does is immediately try to send some text to the PHP script in such a way that the script thinks it is uploading text within a file. it also displays the responses it gets from the server, including what the PHP script sends back.
import java.applet.Applet;
import java.awt.*;
import java.awt.event.*;
import java.io.*;
import java.net.*;
public class test1 extends Applet{
DataOutputStream osToServer;
DataInputStream isFromServer;
HttpURLConnection uc;
String content = "This is a test upload";
public void init(){
try
URL url = new URL( "http://www.mywebpage.com/handleapplet.php" );
uc = (HttpURLConnection)url.openConnection();
uc.setRequestMethod("POST");
uc.setDoOutput(true);
uc.setDoInput(true);
uc.setUseCaches(false);
uc.setAllowUserInteraction(false);
uc.setRequestProperty("Connection", "Keep-Alive");
//uc.setRequestProperty("HTTP_REFERER", "http://applet.getcodebase");
uc.setRequestProperty("Content-Type","multipart/form-data; boundary=7d1234cf4353");
uc.setRequestProperty( "Content-length", ( Integer.toString( content.length() ) ) );
osToServer = new DataOutputStream(uc.getOutputStream());
isFromServer = new DataInputStream(uc.getInputStream());
catch(IOException e)
System.out.println ("Error etc. etc.");
return;
try{
osToServer.writeBytes("------------------------7d1234cf4353\r\nContent-Disposition: form-data; name=\"testfile\"; filename=\"C:testfile.txt\"\r\nContent-Type: text/plain\r\n\r\n");
osToServer.writeBytes(content);
osToServer.writeBytes("\r\n------------------------7d1234cf4353--\r\n");
osToServer.flush();
osToServer.close();
catch (Exception e) {
System.out.println(e);
System.out.println("did not sucessfully connect or write to server");
System.exit(0);
}//end catch
try{
String fieldName="",fieldValue="";
for ( int i=0; i<15; i++ )
fieldName = uc.getHeaderFieldKey(i);
System.out.print (" " + fieldName +": ");
fieldValue = uc.getHeaderField(fieldName);
System.out.println (fieldValue);
}catch(Exception e){
System.out.println ("Didn't get any headers");
     try{        
String sIn = isFromServer.readLine();
                    for ( int j=0; j<20; j++ )
                         if(sIn!=null)
System.out.println(sIn);
                         sIn = isFromServer.readLine();
isFromServer.close();
}catch(Exception e){
          e.printStackTrace();
}//end AudioUp.java
Here's the response I get back from the server:
null: HTTP/1.1 200 OK
Date: Sun, 03 Apr 2005 18:40:04 GMT
Server: Apache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html
null: HTTP/1.1 200 OK
null: HTTP/1.1 200 OK
null: HTTP/1.1 200 OK
null: HTTP/1.1 200 OK
null: HTTP/1.1 200 OK
null: HTTP/1.1 200 OK
null: HTTP/1.1 200 OK
null: HTTP/1.1 200 OK
null: HTTP/1.1 200 OK
<html>
<head>
<title>Handling uploaded files from an applet, etc.</title>
</head>
<body>
No file was uploaded.
</body>
</html>
The <html> and the "No file uploaded" message is simply what the PHP script sends back when it does not detect any uploaded file.
Here is the PHP code on the server:
<html>
<head>
<title>Handling uploaded files from an applet, etc.</title>
</head>
<body>
<?php
if ($testfile)
print "The temporary name of the test file is: $testfile<br />";
$uplfile=$testfile_name;
$uplfile=trim($uplfile);
print "The filename is: $uplfile<br />";
if ($uplfile)
copy ($testfile, "$testfile_name");
unlink ($testfile);
}else{
print "No file was uploaded.";
?>
</body>
</html>

Answer 1

xyz's sample code didn't work - PHP doesn't like the getallheaders line at all. I'm going back to the manual now.
I had another thought. When I first started using PHP, I had problems with ordinary text field uploads from web pages because somewhere in the process, extra blank lines or spurious carriage returns were being inserted into the strings. For example, if I had a place where people could enter their name, password, and brief message, and tried to store the incoming strings in an array, I'd wind up with some thing like:
name
password
brief message
instead of:
name
password
brief message
Which played havoc when trying to read out information by counting lines.
Anyway, the problem was solved by using the trim($string) function on all incoming strings, which I now do as a matter of course. I never could figure out why it was happening though.
Do you think something like that could be happening here?? I mean, if spurious blank lines or carriage returns were being inserted where they shouldn't be, could that be screwing things up in this way? HTTP seems to insist on having new lines and blank lines inserted in just the right places.