mirror of
https://github.com/google/nomulus.git
synced 2025-06-29 15:53:35 +02:00
f2c6021db0
This prevents a possible failure mode of the logging where the logged EPP input XML is very large (which can happen e.g. for domain creates with large SMD values). In those cases, the XML might cause the overall JSON string to be too large to fit within a single log entry [1], in which case it gets split over multiple lines and breaks automatic parsing. This mitigates that case by logging the EPP input (raw and base64-encoded) in a separate log statement so that the more compact metadata (like clientId) and derived values (like ICANN reporting field) will still be in an intact JSON string even in that case, and can still be readily parsed. It's okay if the actual EPP XML is harder to parse, since once we're logging the right metadata fields we shouldn't need to automatically parse the EPP XML in any normal cases. [1] I haven't found this exact limit or splitting algorithm, or whether it's a property of java logging or GAE log ingestion. The GAE logs page does note that a single application log entry (within a request, which can have up to 1000 such entries) maxes out at 8KB, so that might be it: https://cloud.google.com/appengine/docs/standard/java/logs/#writing_application_logs ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=153771335 |
||
|---|---|---|
| .. | ||
| backup | ||
| batch | ||
| bigquery | ||
| builddefs | ||
| config | ||
| cron | ||
| dns | ||
| export | ||
| flows | ||
| groups | ||
| keyring/kms | ||
| mapreduce/inputs | ||
| model | ||
| module | ||
| monitoring | ||
| pricing | ||
| rdap | ||
| rde | ||
| request | ||
| security | ||
| server | ||
| storage/drive | ||
| testing | ||
| tldconfig/idn | ||
| tmch | ||
| tools | ||
| ui | ||
| util | ||
| whois | ||
| xjc | ||
| xml | ||