Hey all,
I've started phase two of GetURI's development, in the form of a CGI interface. So far, the interface supports lists of ham and spam domains, which will be especially handy for discussions on this list, and for those of you hand-checking lists of submitted domains.
I'll also probably at least add a message checker and maybe even an mbox upload feature, based on feedback and testing.
The CGI version produces the same output that the commandline version does. (In fact, it uses some clever tricks to communicate with the commandline version and provide progress to the browser).
http://ry.ca/cgi-bin/geturi.cgi
This will be *especially* useful for all of these "FP" discussions we've been having lately. Now, f'rinstance, if I proclaim topical7074rneds .com should be whitelisted (it shouldn't!!), I could just feed you this:
http://ry.ca/cgi-bin/geturi.cgi?domains=topical7074rneds.com&surbl=ws.su...
...which is ugly, and gets uglier in a hurry with more domains. So, I implemented caching and unique IDs, so you can just do the lookup yourself, and then cut and paste the resulting (potentially much shorter) link that will show up in your Address bar, like so:
http://ry.ca/cgi-bin/geturi.cgi?id=spam-X52p6q8FMYYEINMCsepAG1
These cached results (if referenced by id, as in the last URL) will be available for at least 30 days from their last access time. The page itself describes the caching algorithm in a bit more detail, for those that are interested.
Try it out, please, and make some noise about it. It's experimental (read: I started with an idea in my head and a blank file in my editor about 4.5 hours ago), so there are bound to be some interesting bugs. ;-)
- Ryan
Ryan Thompson wrote:
Hey all,
I've started phase two of GetURI's development, in the form of a CGI interface. So far, the interface supports lists of ham and spam domains, which will be especially handy for discussions on this list, and for those of you hand-checking lists of submitted domains.
I'll also probably at least add a message checker and maybe even an mbox upload feature, based on feedback and testing.
The CGI version produces the same output that the commandline version does. (In fact, it uses some clever tricks to communicate with the commandline version and provide progress to the browser).
Ryan, FYI: with Firefox 1.0 PR - W32 I'm often getting html code as an output - often, not always.
ideas?
Alex
Alex Broens wrote to SURBL Discussion list:
Ryan, FYI: with Firefox 1.0 PR - W32 I'm often getting html code as an output - often, not always.
ideas?
I'm working on that, although I haven't been able to reproduce it. I'm using FireFox on FreeBSD. Can you boil the "sometimes" down to a series of steps that will reliably produce the bug?
In the meantime, I've found a couple of glitches with some wacky MIME stuff that I'm working to correct, which should make it more compliant with everything.
Thanks, - Ryan
Ryan Thompson wrote to surbl@alexb.ch and SURBL Discussion list:
Ryan, FYI: with Firefox 1.0 PR - W32 I'm often getting html code as an output - often, not always.
ideas?
I'm working on that, although I haven't been able to reproduce it. I'm using FireFox on FreeBSD. Can you boil the "sometimes" down to a series of steps that will reliably produce the bug?
In the meantime, I've found a couple of glitches with some wacky MIME stuff that I'm working to correct, which should make it more compliant with everything.
OK, I never did reproduce the bug, but I did reduce my somewhat gratuitous use of multipart/x-mixed-replace to only the necessary cases.
Now, to anyone who saw the HTML code output, it should no longer happen on the main form screen, nor should it appear when you simply follow the "id=" style links. It may still appear when you're actually doing a new query (i.e., after filling out the form and clicking the button). Can you let me know if this still occurs, please?
I'll look at it again tomorrow. It might be an Apache2 configuration issue with x-mixed-replace.
- Ryan
Ryan Thompson wrote:
Ryan Thompson wrote to surbl@alexb.ch and SURBL Discussion list:
Ryan, FYI: with Firefox 1.0 PR - W32 I'm often getting html code as an output - often, not always.
ideas?
I'm working on that, although I haven't been able to reproduce it. I'm using FireFox on FreeBSD. Can you boil the "sometimes" down to a series of steps that will reliably produce the bug?
In the meantime, I've found a couple of glitches with some wacky MIME stuff that I'm working to correct, which should make it more compliant with everything.
OK, I never did reproduce the bug, but I did reduce my somewhat gratuitous use of multipart/x-mixed-replace to only the necessary cases.
Now, to anyone who saw the HTML code output, it should no longer happen on the main form screen, nor should it appear when you simply follow the "id=" style links. It may still appear when you're actually doing a new query (i.e., after filling out the form and clicking the button). Can you let me know if this still occurs, please?
I'll look at it again tomorrow. It might be an Apache2 configuration issue with x-mixed-replace.
no more code visible...
funny is that, for example "drbilly. info" wasn't found in any surbl zone though its definitely in ws, multi & ob
Alex
Alex Broens wrote to ryan@sasknow.com:
I'll look at it again tomorrow. It might be an Apache2 configuration issue with x-mixed-replace.
no more code visible...
Excellent. Apparently, funky content headers are still being sent, so I'll look into that. But I'm glad it at least works for some of you. :-)
funny is that, for example "drbilly. info" wasn't found in any surbl zone though its definitely in ws, multi & ob
GetURI *skips* spam domains that were found in a SURBL, but will shout profusely about ham domains that were found in a SURBL.
It worked OK for me in both cases (checking against multi): http://ry.ca/cgi-bin/geturi.cgi?id=spam-uV3eCSH48hxmMRw6GeUh3x http://ry.ca/cgi-bin/geturi.cgi?id=ham-cmeEVQE6mh9GmNmt5hwW8x
- Ryan
Now, to anyone who saw the HTML code output, it should no longer happen on the main form screen, nor should it appear when you simply follow the "id=" style links. It may still appear when you're actually doing a new query (i.e., after filling out the form and clicking the button). Can you let me know if this still occurs, please?
Hello, I'm using IE6 on XPsp2 and it's showing the html code and all your html content headers as plain text. This version of IE is supposed to be more strict on content headers matching the filename, or something else like that is different. It only happens when I submit the form.
I worked around the issue and the output was great! This will be a helpful tool for daily submissions!