[jira] [Updated] (JCR-3228) WebDav/DavEx remoting throws workspace missmatch exceptions when running on port 80.

["Julian Reschke (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JCR-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julian Reschke updated JCR-3228:
--------------------------------

    Attachment: JCR-3228.diff

This proposed patch solves the case where port 80 is configured, but the remote server does not include the port number in response URIs (this is the likely case).

It does not resolve the opposite case.

However, this may be good enough for now until we do a bigger rewrite of the URI handling.
                
> WebDav/DavEx remoting throws workspace missmatch exceptions when running on port 80. 
> -------------------------------------------------------------------------------------
>
>                 Key: JCR-3228
>                 URL: https://issues.apache.org/jira/browse/JCR-3228
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-spi2dav, jackrabbit-webdav
>    Affects Versions: 2.2.13, 2.4.4, 2.6.2, 2.7.1
>            Reporter: Timothee Maret
>            Assignee: Julian Reschke
>            Priority: Minor
>         Attachments: JCR-3228.diff
>
>
> When running on port 80, the webdav remoting shows unexpected behavior such as listing incomplete folder content.
> Moreover the following exception is thrown:
> The exception I get: java.lang.IllegalArgumentException: Workspace missmatch.
> [org.apache.jackrabbit.spi2dav.IdURICache.add(IdURICache.java:60),
> org.apache.jackrabbit.spi2dav.URIResolverImpl.getItemUri(URIResolverImpl.java:129),
> org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.getItemUri(RepositoryServiceImpl.java:391),
> org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.getPath(RepositoryServiceImpl.java:149),
> org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.getPath(RepositoryServiceImpl.java:138),
> org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.getItemInfos(RepositoryServiceImpl.java:265),
> org.apache.jackrabbit.jcr2spi.state.WorkspaceItemStateFactory.createNodeState(WorkspaceItemStateFactory.java:93),
> org.apache.jackrabbit.jcr2spi.state.TransientISFactory.createNodeState(TransientISFactory.java:97),
> org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.doResolve(NodeEntryImpl.java:990),
> org.apache.jackrabbit.jcr2spi.hierarchy.HierarchyEntryImpl.resolve(HierarchyEntryImpl.java:133),
> org.apache.jackrabbit.jcr2spi.hierarchy.HierarchyEntryImpl.getItemState(HierarchyEntryImpl.java:252),
> org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.getItemState(NodeEntryImpl.java:71),
> org.apache.jackrabbit.jcr2spi.ItemManagerImpl.getItem(ItemManagerImpl.java:199),
> org.apache.jackrabbit.jcr2spi.LazyItemIterator.prefetchNext(LazyItemIterator.java:138),
> org.apache.jackrabbit.jcr2spi.LazyItemIterator.next(LazyItemIterator.java:251),
> org.apache.jackrabbit.jcr2spi.LazyItemIterator.nextNode(LazyItemIterator.java:154),
> com.adobe.drive.connector.adep.GetChildrenHandler.execute(GetChildrenHandler.java:121),
> com.adobe.drive.connector.adep.GetChildrenHandler.execute(GetChildrenHandler.java:43),
> com.adobe.drive.model.internal.synchronization.AssetSynchronizer.execute(AssetSynchronizer.java:432),
> com.adobe.drive.model.internal.synchronization.AssetSynchronizer.synchronizeStructure(AssetSynchronizer.java:352),
> com.adobe.drive.internal.data.manager.DataManager.getChildren(DataManager.java:2602),
> com.adobe.drive.internal.biz.versioncue.service.call.GetChildren$1.call(GetChildren.java:98),
> com.adobe.drive.internal.biz.versioncue.service.call.GetChildren$1.call(GetChildren.java:73),
> com.adobe.drive.model.context.Context.run(Context.java:88),
> com.adobe.drive.internal.biz.versioncue.service.call.GetChildren.executeItem(GetChildren.java:126),
> com.adobe.drive.internal.biz.versioncue.service.call.GetChildren.executeItem(GetChildren.java:50),
> com.adobe.drive.internal.biz.versioncue.service.call.VersionCueCall$1.run(VersionCueCall.java:125),
> com.adobe.drive.internal.biz.versioncue.service.call.VersionCueCall$1.run(VersionCueCall.java:119),
> com.adobe.drive.data.internal.persistence.PersistenceRunner.run(PersistenceRunner.java:119),
> com.adobe.drive.internal.biz.versioncue.service.call.VersionCueCall.execute(VersionCueCall.java:134),
> com.adobe.drive.internal.biz.versioncue.service.VersionCueService.getChildren(VersionCueService.java:269),
> com.adobe.drive.ncomm.versioncue.GetChildren.handle(GetChildren.java:59),
> com.adobe.drive.ncomm.versioncue.VersionCueRequestHandler$1.run(VersionCueRequestHandler.java:185),
> com.adobe.drive.core.internal.jobs.JobHandler$JobWrapper.run(JobHandler.java:270),
> com.adobe.drive.core.internal.jobs.JobHandler$JobWrapper.run(JobHandler.java:286),
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886),
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908),
> java.lang.Thread.run(Thread.java:680)]
> I have tracked this issue and actually the HTTP "Host" header which is used to identify the webdav server does not contain the port (only the host) when running on port 80, whereas it contains the <host>:<port> when running on any other port.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira