The Windows Store supports refunds and as the developer you are responsible for fulfilling those refunds even after Microsoft pays you. That seems reasonable I suppose but there’s no time limit mentioned…
"g. Reconciliation and Offset. You are responsible for all costs and expenses for returns and chargebacks of your app, including the full refund and chargeback amounts paid or credited to customers. Refunds processed after you receive the App Proceeds will be debited against your account. Microsoft may offset any amounts owed to Microsoft (including the refund and chargeback costs described in this paragraph) against amounts Microsoft owes you. Refunds processed by Microsoft can only be initiated by Microsoft; if you wish to offer a customer a refund, directly, you must do so via your own payment processing tools."
dnsxss tool helps you inject via DNS
The U.S. Census Bureau today released a new online service that makes key demographic, socio-economic and housing statistics more accessible than ever before. The Census Bureau’s first-ever public Application Programming Interface (API) allows developers to design Web and mobile apps to explore or learn more about America’s changing population and economy.
THE Fiddler Book straight from the source, EricLaw - the developer of Fiddler!
Fiddler is a wonderful tool with never ending extensibility. With this book I shall master it!
|HTTP Content Coding Token||gzip||deflate||compress|
|An encoding format produced by the file compression program "gzip" (GNU zip)||The "zlib" format as described in RFC 1950.||The encoding format produced by the common UNIX file compression program "compress".|
|Data Format||GZIP file format||ZLIB Compressed Data Format||The compress program's file format|
|Compression Method||Deflate compression method||LZW|
|Deflate consists of LZ77 and Huffman coding|
Compress doesn't seem to be supported by popular current browsers, possibly due to its past with patents.
Deflate isn't done correctly all the time. Some servers would send the deflate data format instead of the zlib data format and at least some versions of Internet Explorer expect deflate data format instead of zlib data format.
I'm done playing Fez. The style is atmospheric retro nastalgia and on the surface the gameplay is standard 2D platformer with one interesting Flatland style game mechanic but dig deeper to find Myst style puzzles. Despite the following I thoroughly enjoyed the game and would recommend it to anyone intrigued by the previous. Five eighths through the game I ran into one of the game's infamous Fez save game breaking issues, but I enjoyed the game enough that I started over before any patches were released and had no further issues.
While playing the game I created some tools to help keep track of my Fez notes (spoilers) including a Pixelated Image Creator that makes it easy to generate data URIs for large, black and white pixelated images, and (spoilers) a Fez Transliteration Tool to help me translate the in-game writing system.
By the URI RFC there is only one way to represent a particular IPv4 address in the host of a URI. This is the standard dotted decimal notation of four bytes in decimal with no leading zeroes delimited by periods. And no leading zeros are allowed which means there's only one textual representation of a particular IPv4 address.
However as discussed in the URI RFC, there are other forms of IPv4 addresses that although not officially allowed are generally accepted. Many implementations used inet_aton to parse the address from the URI which accepts more than just dotted decimal. Instead of dotted decimal, each dot delimited part can be in decimal, octal (if preceded by a '0') or hex (if preceded by '0x' or '0X'). And that's each section individually - they don't have to match. And there need not be 4 parts: there can be between 1 and 4 (inclusive). In case of less than 4, the last part in the string represents all of the left over bytes, not just one.
For example the following are all equivalent:
The bread and butter of URI related security issues is when one part of the system disagrees with another about the interpretation of the URI. So this non-standard, non-normal form syntax has been been a great source of security issues in the past. Its mostly well known now (CreateUri normalizes these non-normal forms to dotted decimal), but occasionally a good tool for bypassing naive URI blocking systems.
As a professional URI aficionado I deal with various levels of ignorance on URI percent-encoding (aka URI encoding, or URL escaping). The basest ignorance is with respect to the mere existence of percent-encoding. Percents in URIs are special: they always represent the start of a percent-encoded octet. That is to say, a percent is always followed by two hex digits that represents a value between 0 and 255 and doesn't show up in a URI otherwise.
The IPv6 textual syntax for scoped addresses uses the '%' to delimit the zone ID from the rest of the address. When it came time to define how to represent scoped IPv6 addresses in URIs there were two camps: Folks who wanted to use the IPv6 format as is in the URI, and those who wanted to encode or replace the '%' with a different character. The resulting thread was more lively than what shows up on the IETF URI discussion mailing list. Ultimately we went with a percent-encoded '%' which means the percent maintains its special status and singular purpose.
A bug came up the other day involving markup containing
<input type="image" src="http://example.com/.... I knew that "image" was a valid input type but it wasn't until that moment
that I realized I didn't know what it did. Looking it up I found that it displays the specified image and when the user clicks on the image, the form is submitted with an additional two name
value pairs: the x and y positions of the point at which the user clicked the image.
Take for example the following HTML:
If the user clicks on the image, the browser will submit the form with a URI like the following:
<input type="image" name="foo" src="http://deletethis.net/dave/images/davebefore.jpg">