Bug Tracker item #3438211, was opened at 2011-11-15 02:10 Message generated for change (Comment added) made by tomhendr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126467&aid=3438211&group_id=250683
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: webui Group: v3.10.x >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Flavio Stanchina (fstanchina) >Assigned to: Tom Hendrikx (tomhendr) Summary: CGI URLs broken with & Initial Comment: Most, if not all, of the URLs generated by dspam.cgi are broken because they use "&" instead of just "&" between CGI parameters. Probably the result of a misguided attempt to replace all the &'s in the webui with HTML entities. The only two places where "&" is OK in dspam.cgi are the string replacements around line 512-518. All the others are in error. ---------------------------------------------------------------------- >Comment By: Tom Hendrikx (tomhendr) Date: 2012-02-22 12:28 Message: The problem is that in dspam.cgi, the same data (mostly the $MURL variable) is used for 2 purposes: - displaying URLs in the webui - redirecting to URLs with HTTP The first needs &, the second one needs & Cleaning up this mixed usage is too cmplicated, so I fixed this by replacing all usages of & in URLs to & in the function that does the HTTP redirects, which should resolve most issues. ---------------------------------------------------------------------- Comment By: Flavio Stanchina (fstanchina) Date: 2011-11-20 15:09 Message: Didn't know that current practices had gotten so backwards. Not sure I can see where this is an improvement, an URL is not element text so there's no reason to quote &, < and > as they're not special. In this particular case, that's also 20 bytes more for each retrain link, in a page that's already too big. I was using Firefox 8.0 on Windows, with English templates. I rebuilt a production server which was still using DSPAM 3.6.8 and the first thing I tested in the web UI was the "all | spam | innocent | whitelisted" links in the history, which by the way I'm the father of -- that very server was running the original implementation. When clicking on links the pages would not come up correctly, i.e. not the right template or not the right filtering in the history, and I blamed it on the unnecessary & in the URLS and immediately went patching the CGI. But if you're sure it should work maybe I was seeing some other problem that fixed itself along the way. Tomorrow hopefully I can revert the changes and see if I'm still seeing those problems. ---------------------------------------------------------------------- Comment By: Tom Hendrikx (tomhendr) Date: 2011-11-18 14:35 Message: Hi Flavio, The updates were added intentionally during an effort to make the generated HTML more complaint to current practices. The URLs should be working in all browsers as they comply with HTML4 specification. Please give us more information on what your actual issue is: - which browser are you using for testing this? - which templates (language) are you using? - is the webui still broken when you switch to english language templates? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126467&aid=3438211&group_id=250683 ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Dspam-devel mailing list Dspam-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-devel
