Nabble - w3.org - www-jigsaw

Re: JigKill error?

2009-10-21T10:24:31Z

I solved the problem. The url should be ended with /.

java org.w3c.jigsaw.admin.JigKill -u admin -p admin --stop
http://127.0.0.1:8009/

Thanks,

Sangmin

On Wed, Oct 21, 2009 at 1:25 AM, Sangmin Park <sangmin.park@...> wrote:

BTW, I got the same problem in my linux machine. Please let me know whether it is Jigsaw's problem, or I am doing wrong.

FYI, I did some tricks in installation stages, because I couldn't compile and install Jigsaw by following installation page. Please consider to apply my tricks into new version of installation page. (Or, tell me if I am doing wrong.)

First, I've added jakarta-oro-2.0.8.jar file (downloaded from oro page) into classes folder. Without the jar file, Jigsaw didn't compile. Second, I've added servlet.jar to CLASSPATH as well as jigsaw.jar, sax.jar, and xp.jar. Finally, I've modified a part of build.xml as follows.

  
  <path id="build.classpath">
   <pathelement path="classes/sax.jar"/>
   <pathelement path="classes/xp.jar"/>

   <pathelement path="classes/servlet.jar"/>
   <pathelement path="classes/jakarta-oro-2.0.8.jar"/>
   <pathelement path="classes/xerces.jar"/>

   <pathelement path="classes/Tidy.jar"/>
   <pathelement path="${build.core.classes}"/>
  </path>

Note that I am working on Jigsaw 2.2.6.

Thanks,
Sangmin

On Tue, Oct 20, 2009 at 9:59 PM, Sangmin Park <sangmin.park@...> wrote:

Hi,

I am having trouble executing JigKill as a commandline. What I want to do is to stop the Jigsaw server with JigKill API. I'll explain what I did, so please correct me the problem that I made.

(1) install Jigsaw as this link: http://www.w3.org/Jigsaw/Doc/User/installation.html

(2) start Jigsaw admin, server

C:\workspace\subjects\original\Jigsaw\Jigsaw>java org.w3c.jigsaw.Main
loading properties from: C:\workspace\subjects\original\Jigsaw\Jigsaw\config\server.props
*** Warning : JigAdmin[2.2.6]: no logger specified, not logging.

JigAdmin[2.2.6]: serving at http://admin-PC:8009/
Jigsaw[2.2.6]: serving at http://admin-PC:8001/

(3) start JigKill in the commandline.

C:\workspace\subjects\original\Jigsaw\Jigsaw>java org.w3c.jigsaw.admin.JigKill -u admin -p admin http://127.0.0.1:8009
java.net.MalformedURLException: For input string: "8009null"

at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)

at java.net.URL.<init>(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.createRemoteFrames(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)

at org.w3c.jigsaw.admin.RemoteResourceFactory.createRemoteResource(Unknown Source)
at org.w3c.jigsaw.admin.AdminReader.readResource(Unknown Source)

at org.w3c.jigsaw.admin.AdminContext.loadRoot(Unknown Source)
at org.w3c.jigsaw.admin.AdminContext.initialize(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)
at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)

java.net.MalformedURLException: For input string: "8009auth-frame"
at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)

at java.net.URL.<init>(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.createRemoteFrames(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)
at org.w3c.jigsaw.admin.RemoteResourceFactory.createRemoteResource(Unknown Source)

at org.w3c.jigsaw.admin.AdminReader.readResource(Unknown Source)
at org.w3c.jigsaw.admin.AdminContext.loadRoot(Unknown Source)

at org.w3c.jigsaw.admin.AdminContext.initialize(Unknown Source)
at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)
java.net.MalformedURLException: For input string: "8009null"
at java.net.URL.<init>(Unknown Source)

at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.createRemoteFrames(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.update(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.enumerateResourceIdentifiers(Unknown Source)
at org.w3c.jigsaw.admin.JigKill.getControls(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)
at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)

java.net.MalformedURLException: For input string: "8009auth-frame"
at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)

at java.net.URL.<init>(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.createRemoteFrames(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.update(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.enumerateResourceIdentifiers(Unknown Source)
at org.w3c.jigsaw.admin.JigKill.getControls(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)
at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)

java.net.MalformedURLException: For input string: "8009http-server"
at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)

at java.net.URL.<init>(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.loadResource(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.getControls(Unknown Source)
at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)
Error : For input string: "8009http-server"

Thanks,

Sangmin

Re: JigKill error?

2009-10-20T22:25:51Z

BTW, I got the same problem in my linux machine. Please let me know whether it is Jigsaw's problem, or I am doing wrong.

FYI, I did some tricks in installation stages, because I couldn't compile and install Jigsaw by following installation page. Please consider to apply my tricks into new version of installation page. (Or, tell me if I am doing wrong.)

First, I've added jakarta-oro-2.0.8.jar file (downloaded from oro page) into classes folder. Without the jar file, Jigsaw didn't compile. Second, I've added servlet.jar to CLASSPATH as well as jigsaw.jar, sax.jar, and xp.jar. Finally, I've modified a part of build.xml as follows.

</path>

Note that I am working on Jigsaw 2.2.6.

Thanks,

Sangmin

On Tue, Oct 20, 2009 at 9:59 PM, Sangmin Park <sangmin.park@...> wrote:

Hi,

I am having trouble executing JigKill as a commandline. What I want to do is to stop the Jigsaw server with JigKill API. I'll explain what I did, so please correct me the problem that I made.

(1) install Jigsaw as this link: http://www.w3.org/Jigsaw/Doc/User/installation.html

(2) start Jigsaw admin, server

C:\workspace\subjects\original\Jigsaw\Jigsaw>java org.w3c.jigsaw.Main
loading properties from: C:\workspace\subjects\original\Jigsaw\Jigsaw\config\server.props
*** Warning : JigAdmin[2.2.6]: no logger specified, not logging.

JigAdmin[2.2.6]: serving at http://admin-PC:8009/
Jigsaw[2.2.6]: serving at http://admin-PC:8001/

(3) start JigKill in the commandline.

C:\workspace\subjects\original\Jigsaw\Jigsaw>java org.w3c.jigsaw.admin.JigKill -u admin -p admin http://127.0.0.1:8009
java.net.MalformedURLException: For input string: "8009null"

at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)

at java.net.URL.<init>(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.createRemoteFrames(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)

at org.w3c.jigsaw.admin.RemoteResourceFactory.createRemoteResource(Unknown Source)
at org.w3c.jigsaw.admin.AdminReader.readResource(Unknown Source)

at org.w3c.jigsaw.admin.AdminContext.loadRoot(Unknown Source)
at org.w3c.jigsaw.admin.AdminContext.initialize(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)
at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)

java.net.MalformedURLException: For input string: "8009auth-frame"
at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)

at java.net.URL.<init>(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.createRemoteFrames(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)
at org.w3c.jigsaw.admin.RemoteResourceFactory.createRemoteResource(Unknown Source)

at org.w3c.jigsaw.admin.AdminReader.readResource(Unknown Source)
at org.w3c.jigsaw.admin.AdminContext.loadRoot(Unknown Source)

at org.w3c.jigsaw.admin.AdminContext.initialize(Unknown Source)
at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)
java.net.MalformedURLException: For input string: "8009null"
at java.net.URL.<init>(Unknown Source)

at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.createRemoteFrames(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.update(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.enumerateResourceIdentifiers(Unknown Source)
at org.w3c.jigsaw.admin.JigKill.getControls(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)
at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)

java.net.MalformedURLException: For input string: "8009auth-frame"
at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)

at java.net.URL.<init>(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.createRemoteFrames(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.update(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.enumerateResourceIdentifiers(Unknown Source)
at org.w3c.jigsaw.admin.JigKill.getControls(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)
at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)

java.net.MalformedURLException: For input string: "8009http-server"
at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)

at java.net.URL.<init>(Unknown Source)
at org.w3c.jigsaw.admin.PlainRemoteResource.loadResource(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.getControls(Unknown Source)
at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)
Error : For input string: "8009http-server"

Thanks,

Sangmin

JigKill error?

2009-10-20T18:59:13Z

Hi,

I am having trouble executing JigKill as a commandline. What I want to do is to stop the Jigsaw server with JigKill API. I'll explain what I did, so please correct me the problem that I made.

(1) install Jigsaw as this link: http://www.w3.org/Jigsaw/Doc/User/installation.html

(2) start Jigsaw admin, server

C:\workspace\subjects\original\Jigsaw\Jigsaw>java org.w3c.jigsaw.Main

loading properties from: C:\workspace\subjects\original\Jigsaw\Jigsaw\config\server.props

*** Warning : JigAdmin[2.2.6]: no logger specified, not logging.

JigAdmin[2.2.6]: serving at http://admin-PC:8009/

Jigsaw[2.2.6]: serving at http://admin-PC:8001/

(3) start JigKill in the commandline.

C:\workspace\subjects\original\Jigsaw\Jigsaw>java org.w3c.jigsaw.admin.JigKill -u admin -p admin http://127.0.0.1:8009

java.net.MalformedURLException: For input string: "8009null"

at java.net.URL.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.createRemoteFrames(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)

at org.w3c.jigsaw.admin.RemoteResourceFactory.createRemoteResource(Unknown Source)

at org.w3c.jigsaw.admin.AdminReader.readResource(Unknown Source)

at org.w3c.jigsaw.admin.AdminContext.loadRoot(Unknown Source)

at org.w3c.jigsaw.admin.AdminContext.initialize(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)

java.net.MalformedURLException: For input string: "8009auth-frame"

at java.net.URL.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.createRemoteFrames(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)

at org.w3c.jigsaw.admin.RemoteResourceFactory.createRemoteResource(Unknown Source)

at org.w3c.jigsaw.admin.AdminReader.readResource(Unknown Source)

at org.w3c.jigsaw.admin.AdminContext.loadRoot(Unknown Source)

at org.w3c.jigsaw.admin.AdminContext.initialize(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)

java.net.MalformedURLException: For input string: "8009null"

at java.net.URL.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.createRemoteFrames(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.update(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.enumerateResourceIdentifiers(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.getControls(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)

java.net.MalformedURLException: For input string: "8009auth-frame"

at java.net.URL.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.createRemoteFrames(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.update(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.enumerateResourceIdentifiers(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.getControls(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)

java.net.MalformedURLException: For input string: "8009http-server"

at java.net.URL.<init>(Unknown Source)

at org.w3c.jigsaw.admin.PlainRemoteResource.loadResource(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.getControls(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.<init>(Unknown Source)

at org.w3c.jigsaw.admin.JigKill.main(Unknown Source)

Error : For input string: "8009http-server"

Thanks,

Sangmin

Jigsaw API?

2009-06-29T13:05:23Z

Hi,

I have been tasked with developing an application that will check a
number of compliancy items for each page in multiple sites. One of the
compliancy items is to ensure that each page validates to XHTML 1.0 strict.

The only way I can figure to automate this process is to build my own
Jigsaw validation server, programmatically send each page of interest to
it, and then parse each report page that Jigsaw produces to determine if
the page is valid or not.

I'm wondering if there is perhaps a more straightforward way to attack
this. I see that the Jigsaw API is defined at
http://www.w3.org/Jigsaw/User/api/Package-w3c.jigsaw.resources.html. Has
anyone built an app using the validation engine directly? Is there
perhaps a tutorial somewhere to that end?

Kind regards,

Chris

12,000 Ravensburger - Michelangelo - "Creation of Adam" jigsaw

2009-01-03T10:40:22Z

Hello,
this is a very rare jigsaw, it's no longer produced, an amazing opportunity to aquire this master piece. Puzzle has not been done, all pieces still in bags.

The box contains 3 bags, each with around 4,000 pieces, you can opt to mix the bags or complete the puzzle in 3 parts, then join up. The full complete size of puzzle is 2.85m wide, 1.38m high.

Please contact if interested. Open to reasonable offers in British Pounds GBP £.

I can post worldwide too!

RE: SoketException - broken pipe

2008-05-12T10:53:01Z

Prashant,

In general, a broken pipe implies that during a standard network communication session (a pipe) the session was abnormally broken in the middle. Examples that might cause this scenario are things like:

- User closes the browser during a request

- User goes to a different site during a request

- User clicks stop button during a request

- Load balancer or firewall improperly closes a connection while checking to see the backend site is available.

Broken pipes are typical in the world of the internet and if the error is “random” then it should be nothing to worry about.

Hope this helps,

Brian

From: www-jigsaw-request@... [mailto:www-jigsaw-request@...] On Behalf Of Prashant Ghodke
Sent: Thursday, May 08, 2008 1:01 AM
To: www-jigsaw@...
Subject: Re: SoketException - broken pipe

Can u pls share the resolution u found for this.

Thanks & Regards,

Prashant Ghodke

Java Developer
Tata Communications,
DGP House,Prabhadevi.
Phone : (+91) (22) 66101210
Mobile: (+91) 9860209887
Email: prashant.ghodke@...

************************************************************************
This e-mail and any accompanying documents or files contain information that is the
property of HAVI Global Solutions, that is intended solely for those to whom this e-mail is addressed
(i.e., those identified in the "To" and "Cc" boxes), and that is confidential, proprietary,
and/or privileged. If you are not an intended recipient of this e-mail, you are hereby
notified that any viewing, use, disclosure, forwarding, copying, or distribution of any of
this information is strictly prohibited and may be subject to legal sanctions. If you have
received this e-mail in error, please notify the sender immediately of any unintended
recipients, and delete the e-mail, all attachments, and all copies of both from your system.

While we have taken reasonable precautions to ensure that any attachments to this e-mail
have been swept for viruses, we cannot accept liability for any damage sustained as a
result of software viruses.
************************************************************************

Re: SoketException - broken pipe

2008-05-07T23:01:03Z

Can u pls share the resolution u found for this.

Thanks & Regards,

Prashant Ghodke

Java Developer
Tata Communications,
DGP House,Prabhadevi.
Phone : (+91) (22) 66101210
Mobile: (+91) 9860209887
Email: prashant.ghodke@...

Jigsaw puzzle machine

2008-04-09T22:25:24Z

Hi Everyone, this is Cathy from China, I am glad to see you all. I am supplier from China on the jigsaw puzzles machines and jigsaw puzzle dies. I am glad to receive all kinds of questiones and advices on puzzle machine, puzzles die and all related items... Best regards! Cathy http://jigsawcutter.com

Jigsaw puzzle machine

2008-04-09T22:23:16Z

RE: Using JpegXMPFrame to remotely access XMP inside JPGs over HTTP

2008-03-31T07:48:35Z

Hi guys,

After receiving no response from anyone else who may have encountered/solved this problem (please see below), I revisited it, had a look at Jigsaw’s source and found fixes to a few problems so that now I can HTTP Get and Put XMP into/out of JPEGs remotely. I’d like to share my finds/fixes with you guys so that they can be added to the next distribution (fixes made to Jigsaw 2.2.6): please find attached the fixed source files (4 of them) and a short readme of what changes I made and why. I’ve also included the readme inline for completeness in the mailing list archive: my fixes can be entirely replicated from Jigsaw 2.2.6 by following its steps. I hope this helps,

BEGIN INLINE README

=================

JPEG XMP fix for Jigsaw

These are fixes to some of Jigsaw's source to properly enable the HTTP Get and Put of XMP into/out of JPEG files remotely. The fixes were made on top of Jigsaw version 2.2.6.

Motivational problems with Jigsaw:

1. org.w3c.tools.jpeg package

a. No writer for XMP data in JPGs

b. No handler for XMP data in JPGs

2. org.w3c.jigsaw.resources.JpegFileResource class

a. Hard-coded to use COM (comment) chunk instead of APP1 chunk (required by XMP specification)

3. org.w3c.jigsaw.frames.JpegXMPFrame class

a. Does not update cache when XMP in JPG is changed

New files included here:

1. org.w3c.tools.jpeg.JpegXMPWriter class (to fix problem 1.a)

Writer for XMP data in JPEGs

a. Copied JpegCommentWriter class

b. Replaced all references to JpegCommentWriter class with JpegXMPWriter class (to fix problem 2.a)

c. Replaced all references to Jpeg.M_COM field with Jpeg.M_APP1 field (to fix problem 2.a)

2. org.w3c.tools.jpeg.JpegXMPHandler class (to fix problem 1.b)

Handler for XMP data in JPEGs

a. Copied JpegCommentHandler class

b. Replaced getComment method with getXMP method:

public String getXMP() throws IOException,JpegException {

JpegHeaders jpeghead = new JpegHeaders(in);

// get the XMP out of the jpeg file

return jpeghead.getXMP();

}

c. Replaced all references to JpegCommentWriter class with JpegXMPwriter

Changes to existing files included here:

1. org.w3c.jigsaw.resources.JpegFileResource class

a. Imported JpegXMPHandler:

import org.w3c.tools.jpeg.JpegXMPHandler;

b. Added newXMPMetadataContent method (similar to newMetadataContent method: to fix problem 2.a):

/**

* Save the given stream as the underlying file content.

* This method preserve the old file version in a <code>~</code> file.

* @param in The input stream to use as the resource entity.

* @return A boolean, <strong>true</strong> if the resource was just

* created, <strong>false</strong> otherwise.

* @exception IOException If dumping the content failed.

public synchronized boolean newXMPMetadataContent(InputStream in) throws IOException {

File file = getFile() ;

boolean created = (!file.exists() || (file.length() == 0));

String name = file.getName();

File temp = new File(file.getParent(), "#"+name+"#") ;

String iomsg = null ;

JpegXMPHandler jpegHandler = new JpegXMPHandler(file);

// We are not catching IO exceptions here, except to remove temp:

try {

FileOutputStream fout = new FileOutputStream(temp) ;

char buf[] = new char[4096] ;

Writer writer = jpegHandler.getOutputStreamWriter(fout);

InputStreamReader reader = new InputStreamReader(in);

for(int got = 0; (got = reader.read(buf)) > 0 ; )

writer.write(buf, 0, got) ;

writer.close() ;

// Fix to ensure Windows releases lock on file...

// Close and mark for garbage collection the following:

// All streams, reader/writers & the JpegHandler

reader.close();

in.close();

fout.close();

reader = null;

in = null;

writer = null;

fout = null;

jpegHandler = null;

// Explicitly call the Garbage Collector

System.gc();

// End fix for Windows

} catch (IOException ex) {

iomsg = ex.getMessage() ;

} finally {

if(iomsg != null) {

temp.delete();

throw new IOException(iomsg);

}

else {

if(getBackupFlag()) {

File backup = getBackupFile();

if(backup.exists())

backup.delete();

file.renameTo(getBackupFile()) ;

}

// with some OSes, rename doesn't overwrite so...

if (file.exists())

file.delete();

temp.renameTo(file) ;

// update our attributes for this new content:

updateFileAttributes() ;

}

return created;

}

2. org.w3c.jigsaw.frames.JpegXMPFrame class

a. Replaced all references to ImageFileResource class with JpegFileResource (so that can use newXMPMetadataContent method below)

b. Replaced reference to ImageFileResource.newMetadataContent method with JpegFileResource.newXMPMetadataContent method (to fix problem 2.a)

c. Added attributeChanged method (similar to JpegComFrame.attributeChanged method: to fix problem 3.a):

/**

* Listen its resource.

public void attributeChanged(AttributeChangedEvent evt) {

super.attributeChanged(evt);

String name = evt.getAttribute().getName();

if((name.equals("file-stamp")) || (name.equals("file-stamp")))

xmpinfo = null;

}

=================

END INLINE README

Fergal Monaghan

Digital Enterprise Research Institute,

Galway,

Ireland.

From: Monaghan, Fergal
Sent: 01 February 2008 16:11
To: www-jigsaw@...
Subject: Using JpegXMPFrame to remotely access XMP inside JPGs over HTTP

Hi guys,

I’ve been using JpegComFrame to access the comment block inside JPGs remotely by asking for e.g. http://sw.deri.org:8001/Photos/20071009162628.jpg;application%2frdf%2bxml

Now I want to switch over to using XMP and JpegXMPFrame: but when I run JigAdmin there isn’t the same dual MIME type options like with JpegComFrame. The only documentation I can find online on using JpegXMPFrame are single sentences like “This class will read the XMP marker from a jpeg file and return it depending on the Accept: header” [1] or “Used to extract XMP from Jpeg images.” [2] >From this I can only guess that it is not possible to simply append the desired MIME type to the end of the URL, but to create an Accept header in the HTTP request. I’ve tried the following Java in an attempt to do this programmatically, with no luck:

URL modelURL = new URL("http://sw.deri.org:8001/Photos/20080201141047.jpg");

HttpURLConnection huc = (HttpURLConnection)modelURL.openConnection();

huc.addRequestProperty("accept", "xmp");

How exactly do I use the Accept: header to retrieve just the XMP metadata over HTTP? What MIME type do I need to specify? Is there any documentation anywhere that could be useful? Help!

Fergal Monaghan,

PhD Candidate,

Digital Enterprise Research Institute,

National University of Ireland, Galway,

IDA Business Park,

Lower Dangan,

Galway,

IRELAND.

[1] http://jigsaw.w3.org/Doc/Programmer/api/org/w3c/jigsaw/frames/JpegXMPFrame.html

[2] http://jigsaw.basemirror.de/Doc/Reference/frames.html

JigsawJpegXMPSource.rar (15K) Download Attachment

RE: Using JpegXMPFrame to remotely access XMP inside JPGs over HTTP

2008-03-31T07:42:44Z

Hi guys,

Fergal Monaghan

Digital Enterprise Research Institute,
Galway,

Ireland.

From: www-jigsaw-request@... [mailto:www-jigsaw-request@...] On Behalf Of Monaghan, Fergal
Sent: 01 February 2008 16:11
To: www-jigsaw@...
Subject: Using JpegXMPFrame to remotely access XMP inside JPGs over HTTP

Hi guys,

I’ve been using JpegComFrame to access the comment block inside JPGs remotely by asking for e.g. http://sw.deri.org:8001/Photos/20071009162628.jpg;application%2frdf%2bxml

Now I want to switch over to using XMP and JpegXMPFrame: but when I run JigAdmin there isn’t the same dual MIME type options like with JpegComFrame. The only documentation I can find online on using JpegXMPFrame are single sentences like “This class will read the XMP marker from a jpeg file and return it depending on the Accept: header” [1] or “Used to extract XMP from Jpeg images.” [2] From this I can only guess that it is not possible to simply append the desired MIME type to the end of the URL, but to create an Accept header in the HTTP request. I’ve tried the following Java in an attempt to do this programmatically, with no luck:

URL modelURL = new URL("http://sw.deri.org:8001/Photos/20080201141047.jpg");

HttpURLConnection huc = (HttpURLConnection)modelURL.openConnection();

huc.addRequestProperty("accept", "xmp");

How exactly do I use the Accept: header to retrieve just the XMP metadata over HTTP? What MIME type do I need to specify? Is there any documentation anywhere that could be useful? Help!

Fergal Monaghan,

PhD Candidate,

Digital Enterprise Research Institute,

National University of Ireland, Galway,

IDA Business Park,

Lower Dangan,

Galway,

IRELAND.

[1] http://jigsaw.w3.org/Doc/Programmer/api/org/w3c/jigsaw/frames/JpegXMPFrame.html

[2] http://jigsaw.basemirror.de/Doc/Reference/frames.html

JigsawJpegXMPSource.rar (15K) Download Attachment

Using JpegXMPFrame to remotely access XMP inside JPGs over HTTP

2008-02-01T08:10:53Z

Hi guys,

I’ve been using JpegComFrame to access the comment block inside JPGs remotely by asking for e.g. http://sw.deri.org:8001/Photos/20071009162628.jpg;application%2frdf%2bxml

Now I want to switch over to using XMP and JpegXMPFrame: but when I run JigAdmin there isn’t the same dual MIME type options like with JpegComFrame. The only documentation I can find online on using JpegXMPFrame are single sentences like “This class will read the XMP marker from a jpeg file and return it depending on the Accept: header” [1] or “Used to extract XMP from Jpeg images.” [2] From this I can only guess that it is not possible to simply append the desired MIME type to the end of the URL, but to create an Accept header in the HTTP request. I’ve tried the following Java in an attempt to do this programmatically, with no luck:

URL modelURL = new URL("http://sw.deri.org:8001/Photos/20080201141047.jpg");

HttpURLConnection huc = (HttpURLConnection)modelURL.openConnection();

huc.addRequestProperty("accept", "xmp");

How exactly do I use the Accept: header to retrieve just the XMP metadata over HTTP? What MIME type do I need to specify? Is there any documentation anywhere that could be useful? Help!

Fergal Monaghan,

PhD Candidate,

Digital Enterprise Research Institute,

National University of Ireland, Galway,

IDA Business Park,

Lower Dangan,

Galway,

IRELAND.

[1] http://jigsaw.w3.org/Doc/Programmer/api/org/w3c/jigsaw/frames/JpegXMPFrame.html

[2] http://jigsaw.basemirror.de/Doc/Reference/frames.html

Jigsaw as an SSL proxy

2007-12-24T06:18:48Z

Hi all,

I am using Jigsaw as a web proxy for a new anti-phishing solution and
need to
configure it as an SSL proxy now. I need to be able to modify returned pages
though, so there must be two SSL-enabled connections, one between the
browser and Jigsaw and the other between Jigsaw and the remote server.

Thus, a request would look like this:

1. The browser initiates an SSL connection C(BJ) to Jigsaw
2. Jigsaw decrypts the request
3. Jigsaw initiates an SSL connection C(JR) to the remote server
4. Jigsaw receives a reply over C(JR)
5. Jigsaw decrypts the reply
6. <my supplied filtering algorithm for the reply>
7. Jigsaw encrypts the filtered reply for C(BJ)
8. Jigsaw sends the encrypted reply to the browser over C(BJ)

Now where would I start to do that? I need some pointers on the
classes where the essential behavior is located so that I can modify
those for my needs.

Any help is really appreciated!

Andreas Krügersen

Jigsaw

2007-11-20T17:20:48Z

Apologize for writing, I only speak Spanish, I need to know if the validator html is available for installation in jigsaw w3c server

Extending webdav?

2007-11-04T16:31:30Z

Hi,

I have had a look through the documentation and I am a little unsure
where I would start if I wanted to extend the webdav implementation,
that is used by Jigsaw. Specifically I am looking to see what it would
take to add support fo RFC 4791, known as Caldav. Caldav is an
extenstion of Webdav, specifically for the exchange of calendar
related data.

Any pointers and/or examples would be very much appreciated.

Andre

2GB file limit.

2007-10-16T03:56:58Z

In all version fo Jigsaw, there has been a limit of the size of the files
you were able to serve, in the 2GB range, because the size was an int
instead of a long.
You can look in [1] for the new classes (source code is in CVS). It should
upgrade nicely from the 2.2 series (It's in place in two production
servers), so everything should be transparent. If you made extensions
using content-length, there will be a warning at compilation time about
possible loss of precision.
Cheers,

[1] http://jigsaw.w3.org/Devel/classes-2.3/

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

Re: clear cache in Jigsaw

2007-10-16T03:53:38Z

On Tue, 16 Oct 2007, Pallavi Joshi wrote:

> Hi everyone,
>
> Is server caching on by default in Jigsaw? If yes, how does one turn it off?

No, it's not. To enable it, you have to add a a property either in the
config file (http-server.props), or via the ProxyProp int eh admin tool.
See [1]

[1] http://www.w3.org/Jigsaw/Doc/Reference/org.w3c.jigsaw.proxy.ProxyProp.html#org.w3c.www.protocol.http.filters

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

clear cache in Jigsaw

2007-10-16T02:08:49Z

Hi everyone,

Is server caching on by default in Jigsaw? If yes, how does one turn it off?

Thanks a lot,
Pallavi

Newbie question

2007-10-07T16:27:17Z

Hello All,

I just subscribed and have not received anything from the list yet. I'd like to describe my objective, background, and one, most important question regarding Jigsaw. All input will be gratefully received.

Objective: I have a potential client who needs a fairly low volume site. The key aspect of the site is the analysis of JPeg picture data POSTed by visitors. The site is for a public-service, non-profit corporation to support its fundraising. It is not a photo sharing service. Analysis of the picture content will require jpeg conversion to bitmap with subsequent analysis and I figured that a portable environment like Java would be the way to go.

Background: I have an Apache server running with which I do development and experimentation. I have no current Apache installations to maintain.

Question: Is anyone using Jigsaw as a production server? I looked in the FAQ for this information and found nothing.

Thanks for any information or guidance offered.

Regards,

Mark Filipak

Introduction

2007-09-08T07:30:31Z

Hi all,

I just subscribed to this list and wanted to introduce myself before posting. I'm Rob and coding and design is my hobby. So do nothing fancy but think I can learn a lot from all posts coming by in this W3C mailinglist.

I have a portal called Indelv.com (http://www.indelv.com/) and post some news on standards just to keep track of what is happening in the field. I know the site is not fully standardized, but I am working on it when I have free time.

So if you have some cool news or found a nice article, send me a note, I will repost some of it on Indelv, so I will not loose track of it. Hope I see nice tips passing by on this mailing list and in the future I might be a bit better and can even assist with answers.

Kind regards and have a good weekend

Rob

Re: ResourceStore and its saving/flush strategies for writing out configuration to disk

2007-07-02T12:17:33Z

On Thu, 28 Jun 2007, Christian Weber wrote:

>
> i have a question regarding the ResourceStore on how changes to the Jigsaw
> configuration are saved/flushed to disk.
> Assuming the following Scenario:
>
> The Jigsaw server is running and the computer crashes, so that Jigsaw has no
> time to shutdown anymore.
> I'm currently examine this Scenario, because this happens a few days ago, not
> to me, but i'm used to examine this case and shall find out, whether it is
> possible that Jigsaw has corrupted the files, because it wasn't able to
> shutdown properly, while the computer crashed, or if it's not possible that
> Jigsaw corrupts the configuration files and isn't able to recover from this
> at the next startup.

> In order to understand why this happend, it would be great, if you could say,
> which of the following "Jigsaws saving Policies" are correct or if it is
> handled different.
>
> These strategies comes into my mind:
> - Does Jigsaw loads the configuration, once at the startup, and further
> doesn't touch the configuration files for
> writing while running, so it only writes the configuration back from
> memory to disk at shutdown?
>
> - Or does Jigsaw additionally writes out configuration changes to disk
> periodically.
>
> - Does Jigsaw flush changes, made in the AdminGUI, immediately to disk after
> commiting and saving them or are the
> changes just altered in memory and get written out at shutdown or some
> periodically save procedure?

Jigsaw's configuration is cached partially (or completely) read from the
disk to the memory. You can tune the number of stores (roughly
corresponding to the number of directories in store a time t), to make it
larger. (org.w3c.jigsaw.loadedstore=..)

When the internal store cache is full, and a new one is read and the LRU
one is flushed. Only if a change happened in the configuration, the
flushed store will effectively be serialized to the disk.
When something is serialized, it is saved first in a temp file, then the
temp file replace the old one.
The same happens ehwn the server is shut down (using the shutdownhook).

When something is edited using the GUI, you need to click on 'Save' to
flush the changes to the disk, otherwise it will be done only during
shutdown, or if the impacted store is flushed.

You can tune also the limit where the stores are no longer flushed
automatically (as they would be too big to save/load and impact the server
performances... Typically over 1000 entries per store).
Hope this answers your questions.
Cheers,

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

ResourceStore and its saving/flush strategies for writing out configuration to disk

2007-06-28T03:13:26Z

Hello all,

i have a question regarding the ResourceStore on how changes to the Jigsaw configuration are saved/flushed to disk.
Assuming the following Scenario:

The Jigsaw server is running and the computer crashes, so that Jigsaw has no time to shutdown anymore.
I'm currently examine this Scenario, because this happens a few days ago, not to me, but i'm used to examine this case
and shall find out, whether it is possible that Jigsaw has corrupted the files, because it wasn't able to shutdown
properly, while the computer crashed, or if it's not possible that Jigsaw corrupts the configuration files and isn't
able to recover from this at the next startup.

After restarting the computer, Jigsaw wasn't able to startup again aborting with this message:
(I replaced the host, path specific entries at the beginning with < >, the rest of the message is untouched )

#loading properties from: <Path to Jigsaw>/Jigsaw/Jigsaw/config/server.props
*** Warning : JigAdmin[2.2.5]: no logger specified, not logging.
JigAdmin[2.2.5]: serving at http://<host>:9444/
FATAL ERROR in element null
Sys : (internal)
Line : 1
Col : 0
org.xml.sax.SAXParseException: no document element
at com.jclark.xml.sax.Driver.parse(Driver.java)
at org.w3c.tools.resources.serialization.xml.XMLReader.parse(XMLReader.java:226)
at org.w3c.tools.resources.serialization.xml.XMLReader.readAttributeHolders(XMLReader.java:259)
at org.w3c.tools.resources.serialization.xml.XMLSerializer.readAttributeHolders(XMLSerializer.java:157)
at org.w3c.tools.resources.store.ResourceStoreManager.<init>(ResourceStoreManager.java:1442)
at org.w3c.jigsaw.http.httpd.initializeResourceSpace(httpd.java:752)
at org.w3c.jigsaw.http.httpd.start(httpd.java:2072)
at org.w3c.jigsaw.daemon.ServerHandlerManager.<init>(ServerHandlerManager.java:280)
at org.w3c.jigsaw.daemon.ServerHandlerManager.main(ServerHandlerManager.java:500)
at org.w3c.jigsaw.Main.main(Main.java:15)
*** salvaging resource manager state...
Unknown error while starting https-server: For input string: "1.tmp"
Exception in thread "main" java.lang.NullPointerException
at org.w3c.jigsaw.http.httpd.checkpoint(httpd.java:828)
at org.w3c.jigsaw.http.httpd.shutdown(httpd.java:1516)
at org.w3c.jigsaw.daemon.ServerHandlerManager.<init>(ServerHandlerManager.java:287)
at org.w3c.jigsaw.daemon.ServerHandlerManager.main(ServerHandlerManager.java:500)
at org.w3c.jigsaw.Main.main(Main.java:15)

In order to understand why this happend, it would be great, if you could say, which of the following "Jigsaws saving
Policies" are correct or if it is handled different.

These strategies comes into my mind:
- Does Jigsaw loads the configuration, once at the startup, and further doesn't touch the configuration files for
writing while running, so it only writes the configuration back from memory to disk at shutdown?

- Or does Jigsaw additionally writes out configuration changes to disk periodically.

- Does Jigsaw flush changes, made in the AdminGUI, immediately to disk after commiting and saving them or are the
changes just altered in memory and get written out at shutdown or some periodically save procedure?

Thanks in advance for any help,
Christian

Re: Jigsaw as a caching proxy server

2007-05-31T07:40:18Z

On Fri, 18 May 2007, David Smiley wrote:

>
>
> I am trying to use Jigsaw as a caching proxy server.
> I followed the instructions here:
> http://www.w3.org/Jigsaw/Doc/User/proxy.html
> I got it working. However, it seems to not be doing any caching (from wire
> traffic observations), but it's possible I'm wrong. Do I need to add the
> "CacheFilter" or some other such component; and basically how is that done?

Yes the CacheFilter needs to be added. The fastest way is to edit
"http-server.props" and put the following lines:
org.w3c.www.protocol.http.filters=org.w3c.www.protocol.http.cache.CacheFilter
org.w3c.www.protocol.http.cache.size=<what you want in bytes>
org.w3c.www.protocol.http.proxy.debug=false
...
See
http://www.w3.org/Jigsaw/Doc/Reference/org.w3c.www.protocol.http.cache.CacheFilter.html

> Might anyone recommend an alternative Java based caching proxy server (not
> necessarily "production" grade but suitable for experimentation)? What's
> drawn me to Jigsaw is that it's Java and that it adheres to the HTTP caching
> related specs well (from my observations of the source).

You can try Rabbit at http://rabbit-proxy.sourceforge.net/
Cheers,

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

Jigsaw as a caching proxy server

2007-05-18T07:10:22Z

I am trying to use Jigsaw as a caching proxy server.
I followed the instructions here:
http://www.w3.org/Jigsaw/Doc/User/proxy.html
I got it working. However, it seems to not be doing any caching (from wire traffic observations), but it's possible I'm wrong. Do I need to add the "CacheFilter" or some other such component; and basically how is that done?

Might anyone recommend an alternative Java based caching proxy server (not necessarily "production" grade but suitable for experimentation)? What's drawn me to Jigsaw is that it's Java and that it adheres to the HTTP caching related specs well (from my observations of the source).

~ David Smiley
MITRE

Jigsaw 2.2.6 is out

2007-04-10T09:42:17Z

The full changelog is here:
http://jigsaw.w3.org/new.html

You can download the release from [1], [2] or [3]
Cheers,

[1] http://jigsaw.w3.org/Distrib/jigsaw_2.2.6.tar.bz2
[2] http://jigsaw.w3.org/Distrib/jigsaw_2.2.6.tar.gz
[3] http://jigsaw.w3.org/Distrib/jigsaw_2.2.6.zip

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

RE: Cookie parsing issue...

2007-03-20T09:42:47Z

On Tue, 20 Mar 2007, Laird, Brian wrote:

> Hey Yves,
>
> Your fix worked perfectly plus it makes a lot more sense then some of
> the other things we were trying. I not too sure where you are on doing
> a 2.2.6 release, but do you think you can integrate this fix and push
> out a minor release (ex: 2.2.5b)?

I may do a 2.2.6 right before doing a separate CVS branch for jdk1.5 and
beyond. I'll try to do so soon.
btw, the sources in CVS reflected the change.
Cheers,

>
> Thanks again for the help,
> Brian
>
> -----Original Message-----
> From: Yves Lafon [mailto:ylafon@...]
> Sent: Tuesday, March 20, 2007 9:03 AM
> To: Laird, Brian
> Cc: www-jigsaw@...; Mrozinski, Ken
> Subject: RE: Cookie parsing issue...
>
> On Tue, 20 Mar 2007, Laird, Brian wrote:
>
>> Hey Yves,
>>
>> Well I spent some time trying to implement your fix and here is what I
>> found:
>>
>> The problem actually exists in the HttpParser. What I think is
>> happening is that the third call to the parser (from the HttpCookieList
>> class) to get the value of the cookie is stopping on the equals sign
>> because that is the delimiter.
>>
>> I think this is easier to explain via an example. Below is an example
>> cookie header.
>>
>> Cookie: HGS$$LocaleCookie=en_US; CHALLENGE_COOKIE=Y3hBsq1lr9AxMTE2;
>> CARDTYPE=card
>>
>> The first call to the parse routine using the cv (ParseState) yields the
>> following: CHALLENGE_COOKIE=Y3hBsq1lr9AxMTE2==
>>
>> This is correct. The next call to the parse routine using the it
>> variable (ParseState) yields the following which is the name of cookie.
>> Now the it variable was initialized with the equals sign as the
>> separator.
>>
>> CHALLENGE_COOKIE
>>
>> The third call to the parse routine is where we lose the equals sign.
>> The routine returns the following:
>>
>> Y3hBsq1lr9AxMTE2
>>
>> In the HttpParser, as it runs through the bytes it is checking to see if
>> it hit the separator. Once it does find the separator it assumes it is
>> complete.
>>
>> Now I looked to see how to fix this and I am kind of at a loss. Here is
>> what we did try to do:
>>
>> - Tried implementing your fix but that resulted in an infinite loop. I
>> think that has to do with how the ParseState is keeping track of the
>> position in the raw bytes and then where the separator shows up.
>
> Yes, I know why now, the test should have been >= 0 instead of < 0. But
> see below:
>
>> - Create a new ParseState object with a separator that would never be
>> found in a cookie. Unfortunately, we could never get it work correctly.
>> I don't think we set the start & end variables correctly.
>>
>> - Change the existing it variables separator to something that would
>> never be found in a cookie. Again that didn't work right.
>>
>> - We looked at just rewriting the whole parse routine but we were afraid
>> that we will introduce some bugs that you have long since resolved due
>> to browser compatibility type stuff.
>
> That would be ideal for this special case, but another way would be to
> tweak the ParseState to go directly to the end of the buffer before
> calling it.toString(raw);
> In that case, as we know the end of the buffer (above you can read
> it.bufend = cv.end;)
> So the "right" fix is to do:
> } else {
> c.setValue(it.toString(raw));
> }
> =>
> } else {
> // we know that we must read everything from the first
> // separator (in case there are multiple instances)
> it.end = cv.end;
> c.setValue(it.toString(raw));
> }
>
>> We are perfectly willing to do the work if you could just provide some
>> direction as to how best to resolve this issue.
>
> The HTTP parser has been optimized to reduce copying while parsing, that's
> why it may be a bit hairy in some cases, but that's the cost of trying to
> be efficient
> Cheers,
>
>

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

RE: Cookie parsing issue...

2007-03-20T09:31:42Z

Hey Yves,

Your fix worked perfectly plus it makes a lot more sense then some of the other things we were trying. I not too sure where you are on doing a 2.2.6 release, but do you think you can integrate this fix and push out a minor release (ex: 2.2.5b)?

Thanks again for the help,
Brian

-----Original Message-----
From: Yves Lafon [mailto:ylafon@...]
Sent: Tuesday, March 20, 2007 9:03 AM
To: Laird, Brian
Cc: www-jigsaw@...; Mrozinski, Ken
Subject: RE: Cookie parsing issue...

On Tue, 20 Mar 2007, Laird, Brian wrote:

> Hey Yves,
>
> Well I spent some time trying to implement your fix and here is what I
> found:
>
> The problem actually exists in the HttpParser. What I think is
> happening is that the third call to the parser (from the HttpCookieList
> class) to get the value of the cookie is stopping on the equals sign
> because that is the delimiter.
>
> I think this is easier to explain via an example. Below is an example
> cookie header.
>
> Cookie: HGS$$LocaleCookie=en_US; CHALLENGE_COOKIE=Y3hBsq1lr9AxMTE2;
> CARDTYPE=card
>
> The first call to the parse routine using the cv (ParseState) yields the
> following: CHALLENGE_COOKIE=Y3hBsq1lr9AxMTE2==
>
> This is correct. The next call to the parse routine using the it
> variable (ParseState) yields the following which is the name of cookie.
> Now the it variable was initialized with the equals sign as the
> separator.
>
> CHALLENGE_COOKIE
>
> The third call to the parse routine is where we lose the equals sign.
> The routine returns the following:
>
> Y3hBsq1lr9AxMTE2
>
> In the HttpParser, as it runs through the bytes it is checking to see if
> it hit the separator. Once it does find the separator it assumes it is
> complete.
>
> Now I looked to see how to fix this and I am kind of at a loss. Here is
> what we did try to do:
>
> - Tried implementing your fix but that resulted in an infinite loop. I
> think that has to do with how the ParseState is keeping track of the
> position in the raw bytes and then where the separator shows up.

Yes, I know why now, the test should have been >= 0 instead of < 0. But
see below:

> - Create a new ParseState object with a separator that would never be
> found in a cookie. Unfortunately, we could never get it work correctly.
> I don't think we set the start & end variables correctly.
>
> - Change the existing it variables separator to something that would
> never be found in a cookie. Again that didn't work right.
>
> - We looked at just rewriting the whole parse routine but we were afraid
> that we will introduce some bugs that you have long since resolved due
> to browser compatibility type stuff.

That would be ideal for this special case, but another way would be to
tweak the ParseState to go directly to the end of the buffer before
calling it.toString(raw);
In that case, as we know the end of the buffer (above you can read
it.bufend = cv.end;)
So the "right" fix is to do:
} else {
c.setValue(it.toString(raw));
}
=>
} else {
// we know that we must read everything from the first
// separator (in case there are multiple instances)
it.end = cv.end;
c.setValue(it.toString(raw));
}

> We are perfectly willing to do the work if you could just provide some
> direction as to how best to resolve this issue.

The HTTP parser has been optimized to reduce copying while parsing, that's
why it may be a bit hairy in some cases, but that's the cost of trying to
be efficient
Cheers,

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

************************************************************************
This e-mail and any accompanying documents or files contain information that is the
property of HAVI Global Solutions, that is intended solely for those to whom this e-mail is addressed
(i.e., those identified in the "To" and "Cc" boxes), and that is confidential, proprietary,
and/or privileged. If you are not an intended recipient of this e-mail, you are hereby
notified that any viewing, use, disclosure, forwarding, copying, or distribution of any of
this information is strictly prohibited and may be subject to legal sanctions. If you have
received this e-mail in error, please notify the sender immediately of any unintended
recipients, and delete the e-mail, all attachments, and all copies of both from your system.

While we have taken reasonable precautions to ensure that any attachments to this e-mail
have been swept for viruses, we cannot accept liability for any damage sustained as a
result of software viruses.
************************************************************************

RE: Cookie parsing issue...

2007-03-20T08:02:42Z

On Tue, 20 Mar 2007, Laird, Brian wrote:

Yes, I know why now, the test should have been >= 0 instead of < 0. But
see below:

RE: Cookie parsing issue...

2007-03-20T07:42:51Z

Hey Yves,

Well I spent some time trying to implement your fix and here is what I found:

The problem actually exists in the HttpParser. What I think is happening is that the third call to the parser (from the HttpCookieList class) to get the value of the cookie is stopping on the equals sign because that is the delimiter.

I think this is easier to explain via an example. Below is an example cookie header.

Cookie: HGS$$LocaleCookie=en_US; CHALLENGE_COOKIE=Y3hBsq1lr9AxMTE2; CARDTYPE=card

The first call to the parse routine using the cv (ParseState) yields the following:
CHALLENGE_COOKIE=Y3hBsq1lr9AxMTE2==

This is correct. The next call to the parse routine using the it variable (ParseState) yields the following which is the name of cookie. Now the it variable was initialized with the equals sign as the separator.

CHALLENGE_COOKIE

The third call to the parse routine is where we lose the equals sign. The routine returns the following:

Y3hBsq1lr9AxMTE2

In the HttpParser, as it runs through the bytes it is checking to see if it hit the separator. Once it does find the separator it assumes it is complete.

Now I looked to see how to fix this and I am kind of at a loss. Here is what we did try to do:

- Tried implementing your fix but that resulted in an infinite loop. I think that has to do with how the ParseState is keeping track of the position in the raw bytes and then where the separator shows up.

- Create a new ParseState object with a separator that would never be found in a cookie. Unfortunately, we could never get it work correctly. I don't think we set the start & end variables correctly.

- Change the existing it variables separator to something that would never be found in a cookie. Again that didn't work right.

- We looked at just rewriting the whole parse routine but we were afraid that we will introduce some bugs that you have long since resolved due to browser compatibility type stuff.

We are perfectly willing to do the work if you could just provide some direction as to how best to resolve this issue.

Thanks again for the help,
Brian

-----Original Message-----
From: Yves Lafon [mailto:ylafon@...]
Sent: Friday, March 16, 2007 7:50 AM
To: Laird, Brian
Cc: www-jigsaw@...
Subject: Re: Cookie parsing issue...

On Fri, 16 Mar 2007, Yves Lafon wrote:

>
> On Fri, 16 Mar 2007, Laird, Brian wrote:
>
>> I hope things are well; it has been a while since we have talked. We
>> came across a problem I am hoping you (or someone who knows the jigsaw
>> code well) can help us with. In a majority of our processing we are
>> using some randomly generated cookie values from a third party as kind
>> of a session identifier. Well a few days ago the value being generated
>> started to look like this (without the double quotes):
>> "0_0RbEAwflUxOTIxNjgyMDMzMw==". We also store this value in memory and
>> compare it to the cookie when the user comes back to our site.

Ok, I located the issue, the parsing is done in
org.w3c.www.http.HttpCookieList, in parse(), the parser has '=' as a
separator, hence the issue you see.

you can try to change
c.setValue(it.toString(raw));

by

StringBuffer sb = new StringBuffer(it.toString(raw));
while (HttpParser.nextItem(raw, it) < 0 ) {
sb.append('=');
sb.append(it.toString(raw);
}
c.setValue(sb.toString());

and see if that fixes the issue.

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

************************************************************************
This e-mail and any accompanying documents or files contain information that is the
property of HAVI Global Solutions, that is intended solely for those to whom this e-mail is addressed
(i.e., those identified in the "To" and "Cc" boxes), and that is confidential, proprietary,
and/or privileged. If you are not an intended recipient of this e-mail, you are hereby
notified that any viewing, use, disclosure, forwarding, copying, or distribution of any of
this information is strictly prohibited and may be subject to legal sanctions. If you have
received this e-mail in error, please notify the sender immediately of any unintended
recipients, and delete the e-mail, all attachments, and all copies of both from your system.

While we have taken reasonable precautions to ensure that any attachments to this e-mail
have been swept for viruses, we cannot accept liability for any damage sustained as a
result of software viruses.
************************************************************************

RE: Cookie parsing issue...

2007-03-16T06:54:22Z

Thanks, Yves! I will try that today to see if that fixes the problem.

Brian

-----Original Message-----
From: "Yves Lafon" <ylafon@...>
To: "Laird, Brian" <BLaird@...>
Cc: "www-jigsaw@..." <www-jigsaw@...>
Sent: 3/16/2007 7:51 AM
Subject: Re: Cookie parsing issue...

On Fri, 16 Mar 2007, Yves Lafon wrote:

Re: Cookie parsing issue...

2007-03-16T06:49:37Z

On Fri, 16 Mar 2007, Yves Lafon wrote:

Re: Cookie parsing issue...

2007-03-16T04:59:53Z

On Fri, 16 Mar 2007, Laird, Brian wrote:

> I hope things are well; it has been a while since we have talked. We
> came across a problem I am hoping you (or someone who knows the jigsaw
> code well) can help us with. In a majority of our processing we are
> using some randomly generated cookie values from a third party as kind
> of a session identifier. Well a few days ago the value being generated
> started to look like this (without the double quotes):
> "0_0RbEAwflUxOTIxNjgyMDMzMw==". We also store this value in memory and
> compare it to the cookie when the user comes back to our site.

Hi Brian, good to see you again!
I'll look into that soon, the parsing of Cookies was a bit weird to allow
Cookies to be sent in multiple headers.
I recently did some modification in Jigsaw for the compilation in jdk1.5
and 1.6, and there may be a new CVS branch with some jdk1.4+ optimizations
in it.

> The problem we are seeing is that the browser is sending in the right
> value but jigsaw is dropping the last two equal signs. One note is that
> the cookie is in the middle of other cookies when you look at the header
> but there is semicolon at end of the value as would be expected.
>
>
>
> A little bit of background on environment:
>
> - We are running 2.2.5a code
>
> - Jigsaw is using JDK 1.5_06
>
> - Solaris 8
>
>
>
> Do you have any thoughts on why this might be happening or at least
> which class the actual parsing of the cookies from the request header is
> happening in? I am perfectly willing to try to make a fix, but I wasn't
> able to easily find where the low level parsing actually took place.
>
>
>
> Thanks in advance for any help on this one,
>
> Brian
>
> ************************************************************************
> This e-mail and any accompanying documents or files contain information that is the
> property of HAVI Global Solutions, that is intended solely for those to whom this e-mail is addressed
> (i.e., those identified in the "To" and "Cc" boxes), and that is confidential, proprietary,
> and/or privileged. If you are not an intended recipient of this e-mail, you are hereby
> notified that any viewing, use, disclosure, forwarding, copying, or distribution of any of
> this information is strictly prohibited and may be subject to legal sanctions. If you have
> received this e-mail in error, please notify the sender immediately of any unintended
> recipients, and delete the e-mail, all attachments, and all copies of both from your system.
>
> While we have taken reasonable precautions to ensure that any attachments to this e-mail
> have been swept for viruses, we cannot accept liability for any damage sustained as a
> result of software viruses.
> ************************************************************************
>

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

Cookie parsing issue...

2007-03-16T00:29:46Z

Hey Yves,

I hope things are well; it has been a while since we have talked. We came across a problem I am hoping you (or someone who knows the jigsaw code well) can help us with. In a majority of our processing we are using some randomly generated cookie values from a third party as kind of a session identifier. Well a few days ago the value being generated started to look like this (without the double quotes): “0_0RbEAwflUxOTIxNjgyMDMzMw==”. We also store this value in memory and compare it to the cookie when the user comes back to our site.

The problem we are seeing is that the browser is sending in the right value but jigsaw is dropping the last two equal signs. One note is that the cookie is in the middle of other cookies when you look at the header but there is semicolon at end of the value as would be expected.

A little bit of background on environment:

- We are running 2.2.5a code

- Jigsaw is using JDK 1.5_06

- Solaris 8

Do you have any thoughts on why this might be happening or at least which class the actual parsing of the cookies from the request header is happening in? I am perfectly willing to try to make a fix, but I wasn’t able to easily find where the low level parsing actually took place.

Thanks in advance for any help on this one,

Brian

Re: New version of Jigsaw ?

2007-02-28T14:06:55Z

On Fri, 23 Feb 2007, Scott Hayes wrote:

> I'm trying to find out if there is a newer version of the jigsaw server that
> is compiled with the latest version of Java 6 (1.6), If not is there a plan
> to compile with the latest Java version?

The latest jars compiled using jdk1.5 are at [1]. I can make a jdk1.6
version, if needed.
Cheers,

[1] http://jigsaw.w3.org/Devel/classes-2.2/20070228/

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves

Re: New version of Jigsaw ?

2007-02-24T15:23:06Z

On Fri, 23 Feb 2007, Scott Hayes wrote:

> Hello all,
>
> I'm trying to find out if there is a newer version of the jigsaw server that
> is compiled with the latest version of Java 6 (1.6), If not is there a plan
> to compile with the latest Java version?

The code in CVS [1] should compile using java 1.5 and 1.6. It is not
released yet (I may create a CVS branch to use some new methods available
in 1.5)
Cheers,

[1] http://dev.w3.org/cvsweb/java/

--
Baroula que barouleras, au tiéu toujou t'entourneras.

~~Yves