Closed Bug 17570 Opened 25 years ago Closed 25 years ago

HTTP Refresh (change columns in bugzilla)

Categories

(Core :: Networking, defect, P2)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: warrensomebody, Assigned: ruslan)

References

(
URL
)

Details

(Whiteboard: [nsbeta2+])

Attachments

(2 files)

proposed patch for mozilla/webshell/src/nsWebShell.cpp
(deleted), patch
Details | Diff | Splinter Review
updated patch
(deleted), patch
Details | Diff | Splinter Review
I did a bugzilla query, got the list of results and tried the Change Columns link at the bottom of the page. The took me to the change columns page, but when I submitted my change, I didn't get a list of results.
Reassigning to Eric.
Whiteboard: [PDT+]
Putting on PDT+...but I think this is a form submission dup.
Whiteboard: [PDT+] → [PDT+] week of 19-Nov-1999
This is the http headers of the response we get back from colchange.cgi: HTTP/1.1 200 OK Date: Tue, 16 Nov 1999 23:28:52 GMT Server: Apache/1.3.4 (Unix) Refresh: 0; URL=buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=RE... Set-Cookie: COLUMNLIST=changeddate severity priority platform owner status r... Connection: close Content-Type: text/html ... The Refresh header seems to be getting ignored. Is Refresh implemented yet? I'll cook up a simplified test case.
Status: NEW → ASSIGNED
OS: Windows NT → All
Hardware: PC → All
Very simple test case works ok, still working on this...
Assignee: pollmann → gagan
URL: http://blueviper.mcom.com/bugs/refres...
Status: ASSIGNED → NEW
Component: Form Submission → Necko
Opps, I tested the very simple case in Nav, so of course it worked. :) This is my failing simple test case: #!/usr/bin/perl print "Refresh: 0; URL=http://mozilla.org Content-Type: text/html <HTML> <BODY> Forwarding you to mozilla.org </BODY> </HTML> "; Accesible from http://blueviper/bugs/refresh.cgi
Summary: [DOGFOOD] can't change columns in bugzilla → [DOGFOOD] HTTP Refresh not implmented
Changing Summary: can't change columns in bugzilla -> HTTP Refresh not implemented
Assignee: gagan → valeski
The refresh header is just another header as far as HTTP in Necko is concerned. Its really the client's responsibility to parse and interpret it. Jud if I remember the plan was to have a common place to trigger the refresh. (common for both HTTP headers and META HTTP-EQUIV or REFRESH in HTML) In my perspective the correct way to implement this would be to let the client of Necko (webshell) watch the OnHeadersAvailable and if a refresh is found trigger exactly the same behaviour as the HTML equivalent of it. Since I am going to be gone for the next few weeks, am assigning this to you (but this should probably just be webshell) Plus you always wanted a free car wash... didn't ya?
note: the date in the whiteboard as put in by someone else prior to my having this bug. I've got other PDT+ bugs that are taking precedence over this right now. I don't have an ETA. This is definately webshell/docloader level functionality. We decided that this stuff would stay out of necko. because I did the meta refresh stuff I'm probably the right person for this.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] week of 19-Nov-1999 → [PDT+] 12/3
Whiteboard: [PDT+] 12/3 → [PDT-] 12/3
Marking PDT-; we can leave without refresh for now.
eric, can you please repost the test URL?
Hm... Let this serve as my reminder to avoid unix commands involving the character * It's up now!
Is this bug related to bug 16161?
*** Bug 16161 has been marked as a duplicate of this bug. ***
I've taken an interest in this bug. If anybody decides to work on it you may want to check with me (woodworth@acm.org) to see what I've learned. Or ideally, I'll have it fixed before anybody else decides to work on this.
I have a fix I'm testing in my local tree. The date in the status whiteboard field indicates that I should have it checked in by Friday.
I've made the webshell (the implementor of nsIRefresh and the one who handles META HTTP-EQUIV refresh) an observer of HTTP response headers. When it finds a refresh header it applies the same logic/code that does the HTTP-EQUIV refreshing. I haven't had a chance to thouroughly test/optimize it. I'll attach the diffs.
Attached patch updated patch (deleted) — — Splinter Review
Target Milestone: M12
updating milestone
Depends on: 13374
Assignee: valeski → travis
Status: ASSIGNED → NEW
assigning to travis as this is being redone in the webshell redesign.
*** Bug 21001 has been marked as a duplicate of this bug. ***
Target Milestone: M12 → M13
Moving to M13 since this has been determined to be PDT-. (Travis, you can still fix this for M12 but it's not a requirement.)
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
Priority: P3 → P2
Summary: [DOGFOOD] HTTP Refresh not implmented → [FEATURE] HTTP Refresh not implmented
Whiteboard: [PDT-] 12/3
Target Milestone: M13 → M14
Replaced "DOGFOOD" with "FEATURE" in summary. Moved to M14.
Summary: [FEATURE] HTTP Refresh not implmented → [FEATURE] HTTP Refresh
Re-summarized.
*** Bug 22148 has been marked as a duplicate of this bug. ***
Blocks: 24739
*** Bug 24678 has been marked as a duplicate of this bug. ***
Putting on beta1 and PDT+ radar since 24678 was to be marked that today.
Keywords: beta1
Whiteboard: [PDT+]
Adding bugzilla change columns to summary to forestall future duplicates when people query for that common problem in the open bugs.
Summary: [FEATURE] HTTP Refresh → [FEATURE] HTTP Refresh (change columns in bugzilla)
Whiteboard: [PDT+] → [PDT+] UNKNOWN
Need an ETA for fix date in Status Whiteboard ASAP please.
removing PDT+ designation, switching to beta2 keyword
Keywords: beta1 → beta2
Whiteboard: [PDT+] UNKNOWN
Moving from M14 to M15. M14 is out already. Please change to even later milestone if needed
Target Milestone: M14 → M15
Guessing at correct QA contact...
QA Contact: cpratt → sairuh
->tever...?
QA Contact: sairuh → tever
Move to M16 for now ...
Target Milestone: M15 → M16
Keywords: nsbeta2
Putting on [nsbeta2+] radar for beta2 fix. Moving over to ruslan per valeski.
Assignee: travis → ruslan
Whiteboard: [nsbeta2+]
Gagan, there's nothing to do here as far as necko is concerned. Has somebody fixed webshell to make it work properly?
*SPAM* - adding mostfreq keyword to bugs with loads of DUPEs. Please aid this effort by adding this keyword to any bugs with more than 15 DUPEs. Gerv
Keywords: mostfreq
Ok. Unfortunately this can't be done via Jud's original patch cuz DocShell would not have the url set at the point when the interceptor would be called. Anyway. I've a different patch which works. Awaiting approval to check in.
Status: NEW → ASSIGNED
Summary: [FEATURE] HTTP Refresh (change columns in bugzilla) → HTTP Refresh (change columns in bugzilla)
checked in
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
re-opening this. Test case works but something is still not working with bugzilla's refresh. The columns do not change when submit is pressed. They do change when you enter the query page for a second time. trace+ output below HTTP/1.1 200 OK Date: Wed, 31 May 2000 23:36:58 GMT Server: Apache/1.3.12 (Unix) Refresh: 0; URL=buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPEN ED&email1=davidm&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=sub string&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom= &chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=substring&long_desc=&lo ng_desc_type=substring&bug_file_loc=&bug_file_loc_type=substring&status_whiteboa rd=&status_whiteboard_type=substring&keywords=&keywords_type=anywords&field0-0-0 =noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse+same+sor t+as+last+time Set-Cookie: COLUMNLIST=severity priority platform status resolution target_miles tone qa_contact status_whiteboard keywords summary ; path=/ ; expires=Sun, 30-Ju n-2029 00:00:00 GMT Set-Cookie: SPLITHEADER=0 ; path=/ ; expires=Sun, 30-Jun-2029 00:00:00 GMT Keep-Alive: timeout=15, max=98 Connection: Keep-Alive Transfer-Encoding: chunked
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The current theory is that Cookies sent as part of the response containing Refresh header are not be processed by the browser till later for some reason. Tom is verifing. We need to close this bug and open up another bug for cookies.
marking fixed
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
verified: NT 2000060108 Refresh is working. Problem with bugzilla appears to be related to cache. Opening new bug.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: