You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be interesting to see the CIDR list in JSON format. We could speed test reading the regular file vs deSerializeJSON().
Another reason for JSON formatted data is it would be easier to update via an automated tool. Such as an import from a list provider or an IIS / Tomcat logs reader of some type in the future.
The text was updated successfully, but these errors were encountered:
I wanted to make it easy to work with CIDRs regardless of format, but there is substantial performance hit when initializing and reading/parsing the file. I think I'll update the script to consume JSON by default and add a function to automatically generate this from a text file or passed var. I'll test this in the next couple of days. I'm considering adding a method to inject CIDRs that aren't in the file.
After review of data available from providers, I'm writing a separate CIDR script to return the ISO 3166 Country Code instead of true/false. This way a developer could block (and accept) access from any country(s) without having to micro-manage the CIDR file and continually add different country ranges to it. It's 9mb of data, so I'm trying to determine the best method of storage and access. I'm considering having it still read a flat file (the format provided), but perhaps hold the information in a database table, cached query or EHCache. I need to test performance to determine the best option... or maybe add all 3 as options for the sake of flexibility. Ideas?
I've not used it before, but CouchDB might be a good option. It's supposed to be fast. Here's a cfml wrapper that looks interesting. http://couchdb.riaforge.org/
It would be interesting to see the CIDR list in JSON format. We could speed test reading the regular file vs deSerializeJSON().
Another reason for JSON formatted data is it would be easier to update via an automated tool. Such as an import from a list provider or an IIS / Tomcat logs reader of some type in the future.
The text was updated successfully, but these errors were encountered: