Ошибка синтаксического анализатора SAX с замыкающим содержимым Apache mod_dav XML в Java

О, чувак, это одна из самых раздражающих и незаметных ошибок, над которыми я когда-либо работал! У меня было такое искушение просто прочитать ответ XML в байтах и ​​вернуть ByteArrayInputStream и вернуть это, хотя я не знал, почему это решило проблему. Получается, что это была моя вина, вроде, технически, но все же...

Так что получается, что если вы читаете контракт API InputStream.read(byte b[], int off, int len), метод никогда не должен возвращать нулевые байты! Если он достигает конца данных, он должен вернуть -1 или заблокировать, пока данные не будут доступны. (Что делать, если вызывающая сторона запрашивает len нуля, неясно, так как это, похоже, не запрещено API. Более современный API указывает, что IllegalArgumentException следует выдавать, если len<1, но я отвлекся.)

Мой HTTPChunkedInputStream автоматически анализирует фрагменты ответа HTTP. Как было написано, если вызывающая сторона HTTPChunkedInputStream.read(byte b[], int off, int len) запросила точно количество байтов, доступных в последнем фрагменте, то входной поток не будет упреждающе пытаться загрузить дальнейшие фрагменты и распознать конец потока. Само по себе это не проблема, но в следующий раз, когда вызывающему объекту потребуется больше байтов, так как алгоритм был написан, мой входной поток попытается прочитать другой фрагмент, распознав, что фрагментов больше не осталось. , а затем указать, что было прочитано ноль байтов! (Обратите внимание, это происходило только в том случае, если вызываемый сначала запрашивал точное количество байтов в последнем фрагменте, а затем запрашивал дополнительные байты.) В любое время после этого он возвращал -1, так как был достигнут конец данных. .

Таким образом, в этом конкретном случае, по какой-то причине, синтаксический анализатор XML запросил точно оставшиеся байты в ответе XML от WebDAV PROPFIND. Затем синтаксический анализатор хотел проверить, есть ли другие символы. Фактическое чтение происходит в UTF8Reader; когда мой входной поток вернул, что было прочитано ноль байтов, это было передано вверх XMLEntityScanner. Ни один из этих классов не знает, как обрабатывать «байты не были прочитаны» — он просто предполагает, что что-то было прочитано. Наконец, XMLDocumentScannerImpl проверяет, что это за "что-то" было в строке 1453:

int ch = fEntityScanner.peekChar();
if (ch == -1) {
    setScannerState(SCANNER_STATE_TERMINATED);
    return XMLEvent.END_DOCUMENT ;
} else{
    reportFatalError("ContentIllegalInTrailingMisc",
            null);
    fEntityScanner.scanChar();
    setScannerState(SCANNER_STATE_TRAILING_MISC);
    return XMLEvent.CHARACTERS;
}

Поскольку конец потока не был указан (он не знает, как обращаться с «ничего»), предполагалось, что там есть «что-то», и это что-то должно быть незаконным конечным содержимым.

Вау! Я исправил свой класс HTTPChunkedInputStream, чтобы он никогда не возвращал нулевые байты из read(). Я измотан — это одна из вещей, которые никогда не всплывают, за исключением редких случаев при определенных условиях. И когда я прочитал байты и вернул их в ByteArrayInputStream, это не появилось, потому что мой код для высасывания байтов из HTTPChunkedInputStream никогда не запрашивал точное количество байтов в последнем фрагменте --- а если и запрашивал, то еще знал, как высосать эти нулевые байты и поместить их в буфер вместе с остальными.