Setup:

• Dakar 7460
• Apache authentication

(09:48:11) Lavr: The applet write 4 status messages while saving.  First is says saving gif, then draw, then map. And the last message is then...
(09:49:04) Lavr: Saved .draw Failed .map Failed .gif Failed
(09:49:15) Lavr: But in reality all 3 were saved.
(09:50:12) Lavr: Very odd error. The java console does not say any errors.
(09:51:19) Lavr: But the twiki window that opens has this error at the bottom. "java.io.IOException: Premature EOF"

---

When trying at the office installation it works after having implemented the fix of renaming twikidraw.tmpl to oopstwikidraw.tmpl.

I will try and install the plugin at my home machine from ZIP instead of from SVN.

I changed the state of the bug to "waiting for feedback" and the feedback will be from me.

-- TWiki:Main.KennethLavrsen

---

Installing the plugin from zip file did not make a difference.

The issue is related to authentication. Something has changed since Cairo.

I have tried many things without much luck. I have been in a situation where the draw plugin could save if I had not logged in. And once I logged in it fails.

-- TWiki:Main.KennethLavrsen

Since I can't reproduce this I'm relying on you to provide more analysis. As I said, the plugin isn't involved in authentication, that's handled entirely by Java.

Some ideas. Can you sniff the transaction? Have you considered your Java version? When the "not logged in" user saved, which user owns the upload? TWikiGuest? When you logged in and it failed, what did the error_log say? Is there anything in the TWiki warning log?

CC

---

I have been sniffing a bit on the client side what is being sent between client applet and Apache when the files are saved.

This is the data seen as ASCII.

Posting the draw file in CAIRO!
--------------------------------------------------------------
POST /twiki/bin/upload/HEJ/TestTopic3 HTTP/1.1
Content-type: multipart/form-data; boundary=89692781418184
Content-length: 694
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.5.0_04
Host: merlin.lavrsen.dk
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Cookie: CGISESSID=93508113ab380693a18c7e4e3fbe3177
Authorization: Basic S2VubmV0aExhdnJzZW46c2FuZCwuLTI0
Cookie: CGISESSID=93508113ab380693a18c7e4e3fbe3177

--89692781418184
Content-Disposition: form-data; name="filename"


--89692781418184
Content-Disposition: form-data; name="noredirect"

1
--89692781418184
Content-Disposition: form-data; name="filepath"; filename="/twiki/pub/HEJ/TestTopic3/tryme.draw"
Content-Type: text/plain


    CH.ifa.draw.standard.StandardDrawing "no_attributes" 3 
        CH.ifa.draw.figures.RectangleFigure "no_attributes" 25 39 63 72  
        CH.ifa.draw.figures.RectangleFigure "no_attributes" 106 59 39 111  
        CH.ifa.draw.figures.RectangleFigure "no_attributes" 33 134 67 5   
--89692781418184
Content-Disposition: form-data; name="filecomment"

TWiki Draw draw file
--89692781418184--




HTTP/1.1 200 OK
Date: Fri, 18 Nov 2005 06:10:11 GMT
Server: Apache/2.0.55 (Unix)
Set-Cookie: CGISESSID=193dbf934eb4b5bcab9ffe43085107f1; path=/
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-1

19
 
OK tryme.draw uploaded

-------------------------------------------------------------------------------
Posting a draw file in Dakar
-------------------------------------------------------------------------------
POST /dakar/bin/upload/Sandbox/TestTopic3 HTTP/1.1
Content-type: multipart/form-data; boundary=89692781418184
Content-length: 750
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.5.0_04
Host: merlin.lavrsen.dk
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Authorization: Basic S2VubmV0aExhdnJzZW46c2FuZHJhcGFuZCwuLTI0
Cookie: CGISESSID=193dbf934eb4b5bcab9ffe43085107f1; TWIKISID=bb5af67f2b01e5af17d7114a7c6f7263

--89692781418184
Content-Disposition: form-data; name="filename"


--89692781418184
Content-Disposition: form-data; name="noredirect"

1
--89692781418184
Content-Disposition: form-data; name="filepath"; filename="/dakar/pub/Sandbox/TestTopic3/newstuff.draw"
Content-Type: text/plain


    CH.ifa.draw.standard.StandardDrawing "no_attributes" 3 
        CH.ifa.draw.figures.RectangleFigure "attributes" "attributes" 1 "Sensitive" "String" "\nTestTopic1" 29 135 105 97  
        CH.ifa.draw.figures.RectangleFigure "no_attributes" 155 48 40 66  
        CH.ifa.draw.figures.RectangleFigure "no_attributes" 44 45 65 68   
--89692781418184
Content-Disposition: form-data; name="filecomment"

TWiki Draw draw file
--89692781418184--



HTTP/1.1 200 OK
Date: Fri, 18 Nov 2005 06:43:35 GMT
Server: Apache/2.0.55 (Unix)
Set-Cookie: TWIKISID=bb5af67f2b01e5af17d7114a7c6f7263; path=/
Content-length: 19
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-15

CGI=HASH(0x8154ddc)OK newstuff.draw uploaded

-------------------------------------------------------------------------------------

Note the difference where Cairo sends a response which is

19
 
OK tryme.draw uploaded

and Dakar sends only one line which is very different.

CGI=HASH(0x8154ddc)OK newstuff.draw uploaded

-- TWiki:Main.KennethLavrsen

---

More updates.

I went through Upload.pm.

It is the ...

$session->redirect( $session->getScriptUrl( $webName, $topic, 'view' ) );

which writes out the session cookie AND the CGI=HASH(0x8154ddc) which clearly causes the error.

I said earlier on chat that the error was still there when I commented out the code line above. This was not true. Apache must be told to write out \n\n before you write anything else. Otherwise Apache returns an error message. This is how you separate header and data.

So by adding \n\n like print "\n\n",'OK ',$message,"\n"; the applet saves the data correctly when the $session->redirect is not called.

So it is in the $session->redirect we have to find the error.

-- TWiki:Main.KennethLavrsen

---

Yet an update

I added this before $session->redirect

print "\n\n", $session->getScriptUrl( $webName, $topic, 'view' );

and it returns this

http://merlin.lavrsen.dk/dakar/bin/view/Sandbox/TestTopic3

which is correct. So it is the $session->redirect() itself that makes the HASH= thing

-- TWiki:Main.KennethLavrsen

---

Normal file attachment.

When upload is called with the form attaching a normal file then upload returns this.

HTTP/1.1 302 Moved
Date: Sat, 19 Nov 2005 08:57:06 GMT
Server: Apache/2.0.55 (Unix)
Set-Cookie: TWIKISID=bb5af67f2b01e5af17d7114a7c6f7263; path=/
Location: http://merlin.lavrsen.dk/dakar/bin/view/Sandbox/TestTopic3
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/plain; charset=ISO-8859-1

1d
OK WelcomeGuest.txt uploaded

I found out that the number sent on the line by itself first is the number of bytes that follows coded in hex.

When the HASH= is sent no number with content length is sent. So maybe the HASH= comes from some undefined variable situation?

The return code when uploading is normal file is 302. When you save with the Drawing Plugin the code is 202. Why is that?

-- TWiki:Main.KennethLavrsen

---

I wish I new more perl - especially object oriented kind. I have never done any object oriented programming before. But I am learning a little by little as I track down this bug. I have come to TWiki.pm function redirect() now.

And I have made a small modification to see where the HASH thing comes from. I am one step close. In redirect in added a print statement.

    my $query = $this->{cgiQuery};
    
    print "\n\nThe query is $query";

And the output is

The query is CGI=HASH(0x8323ddc)

So it is the $this->{cgiQuery}; that returns the HASH thing.

It does this both when you upload normally and when you upload with the applet.

-- TWiki:Main.KennethLavrsen

---

After a hint from Sven I did this code hack

sub redirect {
    my $this = shift;
    my $url = shift;

    ASSERT($this->isa( 'TWiki')) if DEBUG;

    my $query = $this->{cgiQuery};
    
    unless( $this->{plugins}->redirectCgiQueryHandler( $query, $url ) ) {
        if ( $query && $query->param( 'noredirect' )) {
print "\n\nFirst choice";
            my $content = join(' ', @_) . " \n";
            $this->writeCompletePage( $query, $content );
        } elsif ( $this->{client}->redirectCgiQuery( $query, $url ) ) {
print "\n\nSecond choice";
        } elsif ( $query ) {
print "\n\nThird choice";
            print $query->redirect( $url );
        }
    }
}

When you upload a normal file the code goes through the Second choice

When you upload with the drawing applet the code goes through the First choice

-- TWiki:Main.KennethLavrsen

---

Sven D proposed (blind leading the blind) that TWiki.pm line 714 should be changed from

$this->writeCompletePage( $query, $content );

to

$this->writeCompletePage( '', $content );

Cannot say if this breaks something else but it does make the applet not fail when it saves.

-- TWiki:Main.KennethLavrsen

---

Nice one - good detective work!

What you did will work, though the correct solution is to change that code to

$this->writeCompletePage( $content );

the $query was a hangover from the old implementation.

SVN 7546

CC

---

OK - the HASH= is gone. But the applet stilll fails. But we are close.

I have experimented a bit.

The problem is that when the server replies now it first sends a line with a single space. And then the line with the OK.

When you have the $this->writeCompletePage( '', $content ); the first non empty line after the headers and the two new lines is a hex number counting how many characters the message that follows has.

I tried to remove the space in the line above saying.

my $content = join(' ', @_) . " \n";

Note that there is a space in front of \n. If you remove this the applet works again. I don't know what the space is there for.

-- TWiki:Main.KennethLavrsen

Me neither. I suspect a typo.

SVN 7548

CC