Found the answer to my own question >We're seeing the following error (with alarming frequency) >172.17.250.5 ICDIf5me:172.17.250.5 - [24/October/2007:11:30:48 -0500] >eq3 /cat-eq3/scan/MM=9fc873ee8cdc537455d6c511fd49956f:16:31:16.html >search error: Object saved wrong in >/usr/local/interchange/catalogs/eq3/tmp/I/ICDIf5me.9fc873ee8cdc537455d6 c >511fd49956f for search ID ICDIf5me.9fc873ee8cdc537455d6c511fd49956f. Here's the fix. As usual, our feet have some holes in them. We weren't generating all HREFs using the [area] tag. We were instead just using "relative" links. So - we would start by visiting www.foo.com, and on to viewing the product catalog, which would generate a product listing of N items, along with the [more-list] code at the bottom to show the [1][2][3] links. The problem is that the links for the "next" page are generated by interchange, and it uses the __SERVER_URL__ variable, which just happened to be "foo.com" (no leading "www"). Thus, the link for the next page would be foo.com, instead of something like www.foo.com. Ergo, we uld be getting a security violation, because the file would exist, but for the wrong domain. Oops. Example: You're surfing the site, and looking at products, etc. A typical URL is: http://www.foo.coml/cat-abc/scan/fi=products/st=db/co=yes/sf=inactive/tf =prodsort,sku/to=r/se=0/sf=collection/se=homeshopping/ml=16 Then when you want to go to the next page of a particular category, it takes you to to this link http://foo.com/cat-abc/scan/MM=d99f223b81ba65ceda69e9c3522cca1d:48:63:16 .html?mv_more_ip=1&mv_nextpage=results&id=XuLIRLHn&mv_arg=&mv_pc=414 SOLUTION: Make sure all HREFs are generated with HREF=[area ] tags. Darryl _______________________________________________ interchange-users mailing list suppressed http://www.icdevgroup.org/mailman/listinfo/interchange-users
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.