Question 1

Why do I get 'invalid input syntax for type bytea' error when using SabreDAV with PostgreSQL?

Accepted Answer

This error occurs when PostgreSQL version is below 9.5, which is the minimum required by SabreDAV for bytea handling. Upgrade to PostgreSQL 9.5 or later:

```bash
# Example for Ubuntu
sudo apt-get upgrade postgresql-9.5
```

Refer to the installation documentation for full requirements.

Question 2

How to stop Baikal from flooding PHP error log with 'No Authorization: Basic header found' messages?

Accepted Answer

Upgrade Baikal to a version that includes the fix from PR #840 (merged after v0.6.0). This update suppresses the unnecessary logging of missing Basic auth headers, which are normal client behaviors. If you cannot upgrade, apply the patch manually to `vendor/sabre/dav/lib/DAV/Auth/Backend/AbstractBasic.php` or configure your logger to ignore 4xx debug messages. For permanent resolution, use the latest Baikal release.

Question 3

Why does moving a folder or file fail without error in sabre/dav?

Accepted Answer

A bug in `Directory::moveInto()` caused it to always return `true` even when the underlying `rename()` call failed. This has been fixed by making `moveInto()` return the result of `rename()` directly.

**Fix**: Apply the patch from [PR #1143](https://github.com/sabre-io/dav/pull/1143) (merged). The corrected code should be:

```php
function moveInto($targetName, $sourcePath, DAV\INode $sourceNode) {
    if (!$sourceNode instanceof self && !$sourceNode instanceof File) {
        return false;
    }
    return rename($sourceNode->path, $this->path . '/' . $targetName);
}
```

**Note**: Even without this fix, properly configured sabre/dav installations convert PHP warnings (like from `rename()`) into exceptions, so the bug may not surface if your error handler is set up correctly. Ensure warnings are escalated to exceptions if you cannot upgrade immediately.

Question 4

How to fix 'SQLSTATE[22P02] invalid input syntax for type bytea' in Sabre/DAV with PostgreSQL when saving calendar events with commas?

Accepted Answer

The error occurs when Sabre/DAV stores data containing a backslash-escaped comma (e.g., `\,`) in a PostgreSQL `BYTEA` column. PostgreSQL interprets the backslash, causing an invalid bytea input error.

**Workaround**: Use a server plugin that escapes single backslashes to double backslashes before the data is written:

```php
<?php

namespace Custom\CalDAV\Sanitizer;

use Sabre\DAV\ServerPlugin;
use Sabre\DAV\Server;

class SanitizerPlugin extends ServerPlugin
{
    function initialize(Server $server)
    {
        $server->on("beforeCreateFile", [$this, "handleSanitizationCreate"]);
        $server->on("beforeWriteContent", [$this, "handleSanitizationUpdate"]);
    }

function handleSanitizationCreate($path, &$data, \Sabre\DAV\ICollection $parent, &$modified)
    {
        if (is_resource($data)) {
            $data = stream_get_contents($data);
        }
        $data = str_replace('\\', '\\\\', $data);
    }

function handleSanitizationUpdate($path, &$data)
    {
        if (is_resource($data)) {
            $data = stream_get_contents($data);
        }
        $data = str_replace('\\', '\\\\', $data);
    }
}
```

Register this plugin in your `server.php` configuration. This fixes the immediate issue.

**Long-term fix**: The `Sabre\CalDAV\Backend\PDO` and `Sabre\CardDAV\Backend\PDO` backends should bind `calendardata` and `carddata` columns using `PDO::PARAM_LOB`, similar to `Sabre\DAV\PropertyStorage\Backend\PDO::propPatch()`. Monitor the [Sabre/DAV issue tracker](https://github.com/sabre-io/dav/issues/1587) for an official update.

Question 5

Why do I see 'No 'Authorization: Digest' header found' in Apache logs even though CardDAV/CalDAV sync works?

Accepted Answer

This is normal behavior during HTTP Digest authentication. Clients first send an unauthenticated request. The server responds with a 401 status and `WWW-Authenticate` header, generating the log entry. The client then re-sends the request with proper `Authorization: Digest` header. If the client does not cache credentials, this handshake repeats for each request, causing many log lines. This affects Android (e.g., CardDAV-Sync free) and iOS. Mitigation: Ensure clients cache authentication after initial challenge. No server-side fix required; the project’s digest implementation (`sabre/http`) handles this correctly without Apache's `mod_digest`.

sabre/dav

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects