This is youtube's 500 page. I wonder if someone knows how the 'information' is encoded. It is not base64. Does anyone know how to decode it.<p>http://paste.pm/raw/dme
An analysis of this can be found here:
<a href="http://www.cambus.net/decoding-youtube-http-error-500-message/" rel="nofollow">http://www.cambus.net/decoding-youtube-http-error-500-messag...</a>
The code is indeed very useful to debug issues. When asked for it by YouTube, please provide the actual text rather than a screenshot...I get sent the screenshot a lot and then I have to use OCR software in order to decode it.
Why do you assume it is not base64 encoded? I have always come to believe it is some encrypted data. If I was Google I would probably give every server a UUID and a symmetric key. If an error occurs encrypt (and authenticate) the stacktrace and other debug information with that symmetric key and prepend the UUID. As a developer you can then find out the server that produced the error message, log in via SSH and decrypt the debug information.<p>But it would be interesting to collect a lot of this error messages to check if they appear to be completely random.
It is non-standard base64: it uses '_' and '-' instead of '+' and '/'. You can read in Wikipedia at <a href="https://en.wikipedia.org/wiki/Base64" rel="nofollow">https://en.wikipedia.org/wiki/Base64</a>
It is surely an encrypted stack trace, encoded in base64, which is probably being spit out by the load balancer proxy. I would not be surprised if Youtube developers used their own Chrome extension for making that binary meat readable.<p>I have once set out to write a module for Nodejs for the same purpose, but never finished it. Can't really see a downside in this way of reporting errors.
Perhaps questions like this one should be asked somewhere else, possibly StackOverflow: <a href="http://stackoverflow.com/questions/21681084/decoding-youtubes-error-500-page" rel="nofollow">http://stackoverflow.com/questions/21681084/decoding-youtube...</a>
1. Non-standard base64 and
2. Definitely Compressed ... by guess would be snappy compression
3. Possibility of serialization using protocol buffer
4. not sure if such information would be encrypted after such a server failure