Closed
Bug 59238
Opened 25 years ago
Closed 10 years ago
in NS6, this url doesn't reload when it should
Categories
(Core :: Networking: HTTP, defect)
Core
Networking: HTTP
Tracking
()
VERIFIED
WONTFIX
People
(Reporter: Brade, Unassigned)
References
()
Details
this is blocking bug #55914
I can't load this url on Macintosh:
http://166.90.144.66/cgi-bin/nph-dtspush.cgi?camera=jpeg/surfline04/
cam0.%%08ld.rgb888.enc
Others (cyril_bortolato@yahoo.com) haven't been able to load this url on Linux.
It loads fine on 4.x (at least initially that is).
Expectation: Page should load or I should get some kind of dialog/message telling
me why it couldn't load.
Comment 1•25 years ago
|
||
The problem here is a bogus URL. "%%" is not a valid encoding for the "%"
character in a URL. Changing the URL to:
http://166.90.144.66/cgi-bin/nph-dtspush.cgi?camera=jpeg/surfline04/cam0.%2508ld.rgb888.enc
(note the %25 instead of %%) makes it work in Mozilla for me...
| Reporter | ||
Comment 2•25 years ago
|
||
fixing url above; thanks bzbarsky@mit.edu!
Changing summary in case what I am seeing is a bug... I don't see this document
ever reload... I think to test/confirm 55914, we need this url to reload.
Pam--can you confirm the expected behavior for this url?
Summary: unable to load this url in NS6 → in NS6, this url doesn't reload when it should
Comment 3•25 years ago
|
||
If I just go to the page, it does not reload.
If I go to the page and then hit the reload button, it starts reloading over and
over again (this I assume is the intended behavior). Same if I hit C-r.
This is not a cache issue; I have tried all three cache settings (validate
always/once/never) and I see the same behavior for all.
Comment 4•25 years ago
|
||
win98 200110604 trunk - the inital page never breaks connection to server, but
image is NOT reloaded the image.
Reloading the page startes loading the image all the time, too fast even so I
can't make out the image
Updated•25 years ago
|
Target Milestone: --- → Future
Is this the same bug, or something completely different ?
This morning I add a little bit of text to
http://piclist.org/techref/microchip/compcon.htm?edit
and hit the ``update'' button.
(um... you won't be able to see the edit field, sorry. Do I need to get
a special Bugzilla account set up ?).
Later I go to page
http://piclist.org/techref/microchip/compcon.htm
and hit the ``edit'' button which returns me to the same URI,
http://piclist.org/techref/microchip/compcon.htm?edit
.
I expect Mozilla to load the current text, including the stuff I added this
morning. Unfortunately, I see yesterday's text (from the Mozilla cache), so when
I make a few changes and hit ``update'', these changes are saved, but the text I
added this morning is lost forever. Oops.
Workaround: every time I go to page
http://piclist.org/techref/microchip/compcon.htm?edit
I hit the ``refresh'' button, which loads in the current text. Then I can make
changes and hit ``update'' without loading anything.
Late breaking news:
I *thought* that sticking the question mark (``?'') in the URI indicated
``don't cache me'', but
http://www.w3.org/DesignIssues/Axioms.html
specifically says it *is* OK to cache all URIs, even those that include the
question mark.
So this annoyance is really part of Mozilla's standards compliance.
--
dc
Comment 8•23 years ago
|
||
dcary: if you want to prevent caching, you HAVE to use headers; there is much
information from http://www.squid-cache.org if you look.
Basically, set expires: to now, and last-modified to now, and maxage and
s-maxage to 0.
If you're using PHP:
Header("Cache-control: must-revalidate maxage=0, s-maxage=0") should do it for you.
Comment 9•23 years ago
|
||
Header("Cache-control: must-revalidate, maxage=0, s-maxage=0")
make sure you include all the commas ;-)
Comment 10•20 years ago
|
||
-> default owner
Assignee: darin → nobody
QA Contact: tever → networking.http
Target Milestone: Future → ---
Updated•20 years ago
|
Priority: P3 → --
Comment 11•14 years ago
|
||
Is this still an issue ?
The testcase is dead...
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Updated•10 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•