• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 242
  • Last Modified:

POST submitted message not captured in simple Java based HTTP-Socket Server

Hi again all,

this question is extended from my previous question on this thread:

http://www.experts-exchange.com/Programming/Programming_Languages/Java/Q_21788831.html#16325918

The code right now is pretty much the same but the altered HTTP-Response with \r\n and this while loop:

while ((lStrLineReadFromRequest = lBufferedReader.readLine()).length()!=0)
           {
               System.out.println( lStrLineReadFromRequest );
           }

I'm now able to buffer-in, print out the GET-Request from web browser, and send out the needed response back to the client. Now, we are experimenting with POST-Request to the socket, using this simple HTML Form:

<HTML>
 <HEAD>
  <TITLE>
   HTTP request POST body
  </TITLE>
 </HEAD>
 <BODY>
  <FORM action="http://localhost:9999" method="post">
   <INPUT type="text" value="we need to see this in our HTTP request stream" name="FEtxtSomeValue">
   <BR>
   <INPUT type="submit" name="FEsbtMain">
  </FORM>
 </BODY>
</HTML>

Catched POST-Request with Livehttpheader plugin from firefox:

POST / HTTP/1.1
Host: localhost:9999
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 84
FEtxtSomeValue=we+need+to+see+this+in+our+HTTP+request+stream&FEsbtMain=Submit+Query

The Socket server is able to catch all above text except the last line, the submitted POST-message. I've tried to use this endless while-loop to catch all the POST-Request sent to the Socket-Server:

while (true)
           {
              lStrLineReadFromRequest = lBufferedReader.readLine();
               System.out.println( lStrLineReadFromRequest );
           }

 but the last line just seems to be missing / uncatchable from the request.

Any suggestions please?

Thank you very much :)

-eck-
0
-eck-
Asked:
-eck-
  • 7
  • 7
  • 6
  • +1
2 Solutions
 
CEHJCommented:
>>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Is that really the browser submitting it, or your program?
0
 
-eck-Author Commented:
Hi CEHJ,

it's a request from my browser, I'm opening a socket server locally, and using my browser to send an HTTP-Request to my local socket server.

-eck-
0
 
CEHJCommented:
>>
while (true)
           {
              lStrLineReadFromRequest = lBufferedReader.readLine();
               System.out.println( lStrLineReadFromRequest );
           }
>>

Should be more like

while ((lStrLineReadFromRequest = lBufferedReader.readLine()) != null && lStrLineReadFromRequest.trim().length() > 0) {
               System.out.println( lStrLineReadFromRequest );
}
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
CEHJCommented:
Or, marginally more useful:


while ((lStrLineReadFromRequest = lBufferedReader.readLine()) != null && (lStrLineReadFromRequest = lStrLineReadFromRequest.trim()).length() > 0) {
               System.out.println( lStrLineReadFromRequest );
}
0
 
-eck-Author Commented:
Hi CEHJ,

thanks for the reply, I've tried your while loop suggestion, and unfortunately I get the same effect I had using my old while-loop. The POST-Submitted msg is still not recieved by my socket server console :-/

-eck-
0
 
CEHJCommented:
Is it blocking?
0
 
-eck-Author Commented:
>>Is it blocking?

since the Socket should stream in all incoming request, I can't imagine that the Socket server explicitely block the only last part but let in the rest of the header. But, of course, I'm not sure...

-eck-
0
 
objectsCommented:
> Should be more like
> while ((lStrLineReadFromRequest = lBufferedReader.readLine()) != null && lStrLineReadFromRequest.trim().length() > 0) {

no it shouldn't, that won't make any difference.


0
 
objectsCommented:
If there is a Content-Length specified then you need to use it to determine how many bytes to read (instead of using readLine()).
0
 
CEHJCommented:
>>I can't imagine that the Socket server explicitely block the only last part but let in the rest of the header.

That's precisely the part it would block if blocking.

You can determine quite easily if it's blocking by whether the reading thread finishes or not
0
 
DaFouCommented:
I have had similar problems.

-eck- is asking. How do we read all of the HTTP request ( including post body and all ) and once all is read break out of the loop.

right -eck-?
0
 
-eck-Author Commented:
>> -eck- is asking. How do we read all of the HTTP request ( including post body and all ) and once all is read break out of the loop. right -eck-?

DaFou: Indeed, we have implemented this for GET-Request, and successfully stream-in and print-out everything. This doesn't work completely with POST yet.

>> If there is a Content-Length specified then you need to use it to determine how many bytes to read (instead of using readLine()).
objects: Very interesting point, I'm googling around right now to see what I can read out of the Content-Leght

>>You can determine quite easily if it's blocking by whether the reading thread finishes or not
CEHJ: Hmmm, unfortunately, I have no idea how the determine this, yet.

-eck-

0
 
-eck-Author Commented:
Update: I've tried, switching back the while loop to read characters instead of lines:

while ((lIntLineReadFromRequest = lBufferedReader.read())!= -1)
            {
                   System.out.print( ( char )lIntLineReadFromRequest );
      }

now I'm able to see the submitted POST-Message.

It seems that every browser-client leave out an empty line between the POST-Request Header and actual POST-Message. This explains why the loop exitted prematurely before the actual POST-Message are printed out, this doesn't explain why the me unlimited loop doesn't cath the actial POST-Message though.

Then, we're back to the first question again :-(.
- Is there any parameter I can use to exit the while-loop above after a browser finished sending its GET/POST-Request? - or Is by parsing the "Content-Length" variable and reuse it the only way possible?

Thanks a lot :-)

-eck-
0
 
objectsCommented:
Thats what Content-Length is for. If its defined you need to use that value.
See the rfc for more details.
0
 
objectsCommented:
> It seems that every browser-client leave out an empty line between the POST-Request Header and actual POST-Message.

as it should
0
 
CEHJCommented:
You need to use a combination of linewise and char-wise parsing. Start reading char-wise after having read the Content-Lenth line
0
 
objectsCommented:
try something like:

String line = null;
int content_length=0;
BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
while((line=in.readLine())!=null && line.length()>0)
{
     System.out.println(line);
     if(line.toUpperCase().startsWith("CONTENT-LENGTH:"))
     {
          content_length=Integer.parseInt(line.substring(15).trim());
     }
}

char[] buffer=new char[1024];
if(content_length>0)
{
    int remaining = content_length;
    int nread = 0;
    while(remaining>0 && (nread=in.read(buffer,0,remaining))!=-1)
    {
         remaining -= nread;
         System.out.println(new String(buf, 0, nread));
    }
}
in.close();

0
 
-eck-Author Commented:
Hi all, sorry I was away yesterday.

Perfect, the code works just the way it should be, u've helped me a lot, thanks again :-D

Regards,

-eck-
0
 
CEHJCommented:
:-)
0
 
objectsCommented:
> You need to use a combination of linewise and char-wise parsing. Start reading char-wise after having read the Content-Lenth line

Thats incorrect.
0

Featured Post

How to Use the Help Bell

Need to boost the visibility of your question for solutions? Use the Experts Exchange Help Bell to confirm priority levels and contact subject-matter experts for question attention.  Check out this how-to article for more information.

  • 7
  • 7
  • 6
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now