- changed status to wontfix
Redundant (?) element of an URL
What #Linde is doing at the end of http://poliqarp.wbl.klf.uw.edu.pl/extra/linde/index.djvu?djvuopts&page=2444&zoom=width&showposition=0.533,0.848&highlight=477,2745,137,54,ffff00#Linde?
For this URL djview4 doesn't use the showposition parameter. Perhaps this is somehow related?
Comments (16)
-
repo owner -
reporter This is not an URL from the server, at least not directly, but created by Copy URL.
-
repo owner The # part comes from the server.
-
reporter Actually such URLs are never handled by a server, but by djview4. Nevertheless investigating the origin of the redundant part is an issue in marasca, not djview4poliqarp.
-
repo owner First the URL is passed from djview4 to the server to retrieve DjVu file. As we allow external servers, we cannot be sure they don't use # part of URL to retrieve the file.
We already had an example of server using djview4 parameters: appending highlight color to highlight= parameter of URL broke redirection on the wbl server.
-
reporter - changed status to open
The problem requires reinvestigation in some future as it is quite nasty: the highlights for added entries don't work. It does not appear systematically, I will try to find a way to reproduce it.
-
reporter - marked as critical
I've added some entries to an index and the bug hits again, making the new entries unusable without some hand-editing:
Wanda;http://djvu.szukajwslownikach.uw.edu.pl/linde-t/06/index.djvu?djvuopts&page=216&zoom=width&showposition=0.541,0.788#LindeNowy&highlight=2443,1292,269,111;::018-2-32-0-0 __ _ ___::;※ a:imię Wenda;http://djvu.szukajwslownikach.uw.edu.pl/linde-t/06/index.djvu?djvuopts&page=216&zoom=width&showposition=0.541,0.788#LindeNowy&highlight=2802,1294,321,98;!::018-2-33-0-0-s_ _ ___::;※ a:imię
-
Actually, I've checked using Wireshark what requests are made by djview and djview-poliqarp (2d2215e) when requesting
http://djvu.szukajwslownikach.uw.edu.pl/linde-t/06/index.djvu?arg=a&djvuopts&page=216&arg2=val2&zoom=width&showposition=0.541,0.788#LindeNowy&highlight=2443,1292,269,111
(address as jsbien's, but with
arg=a
added before djvuopts andarg2=val2
after)Surprisingly the request was
GET /linde-t/06/index.djvu?arg=a
.As is, neither djview nor djview-poliqarp inform server of anything after
djvuopts&
Regardless of whether this is expected behavior, anything after
#
(that is, 'fragment' section of URI) can be safely removed.According to RFC3986 (URI: Generic Syntax), section 3.5.:
"the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme"
If any server uses part after '#' to change returned resource, it is deeply broken.
-
repo owner I don't have enough time now to reverse-engineer the server source code.
Is it possible to see a page with a link containing hash symbol?
-
Yes, but any options after
#
are discarded.So the problem starts when adding new djvuopts, since they are added at the end, possibly after
#LindeNowy
which is apparently part of the search result URL. -
reporter Please not the problem is specific to djview4poliqarp, it doesn't occur in djview4, so I would not be sure it is the problem of the server. Moreover the problem started to appear when the server itself was already stable. Anyway, a brute force approach consisting in removing the offending part before storing it in the index or clipboard seems sufficient.
-
repo owner How can I obtain URL with # in djview4poliqarp?
-
reporter E.g. adding an entry to a dictionary.
However we can put the issue on hold, I have some new ideas which I will check in the coming days.
-
repo owner I meant: how can I see the # link served by server or djview4poliqarp. I understand I can add such link manually, but where does it come from?
-
reporter Adding an entry doesn't mean adding the link manually, the link for the entry is created by djview4poliqarp.
-
reporter - changed status to on hold
As I said, I want to check some ideas.
- Log in to comment
I am just using what is provided by the server. As we cannot be sure how the server handles # in URL, I think it is better to keep it as it is (see the problems with redirection).