Need to handle 505 response




19 years ago
3 years ago


(Reporter: ruslan, Unassigned)


Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta2-])



19 years ago
Need to handle 505 response (http version not supported). I've never seen it 
actually happening, but if we go by the book - we need to implement it.


19 years ago
Keywords: nsbeta2
Target Milestone: --- → M17

Comment 1

19 years ago
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]

Comment 2

18 years ago
What should happen if we receive a 505?

Comment 3

18 years ago
We should resubmit the original request, downgrading http version.

Comment 4

18 years ago
From what I can tell, the handler code for this needs to be added to
nsHTTPServerListener::OnDataAvailable in the

if (mResponse)


Am I correct?

Comment 5

18 years ago
I has to be along the line of implementation of SSL CONNECT handling, look into 

Comment 6

18 years ago
So we couldn't detect it at the same place we detect "304" responses?

Comment 7

18 years ago
-> future
Target Milestone: M17 → Future

Comment 8

18 years ago
pulling in ruslan's necko bugs ->darin
Assignee: ruslan → gagan
Target Milestone: Future → M19

Comment 9

18 years ago
Assignee: gagan → neeti
Target Milestone: --- → mozilla1.0

Comment 10

18 years ago
mass move, v2.
qa to me.
QA Contact: tever → benc

Comment 11

17 years ago
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
Target Milestone: mozilla1.0 → mozilla1.0.1


17 years ago
Target Milestone: mozilla1.0.1 → Future

Comment 12

16 years ago
moving neeti's futured bugs for triaging.
Assignee: neeti → new-network-bugs

Comment 13

16 years ago
-> http
Assignee: new-network-bugs → darin
Component: Networking → Networking: HTTP
QA Contact: benc → httpqa


16 years ago
QA Contact: httpqa → tever

Comment 14

16 years ago
fair enough... but it'd be nice if there were an actual testcase /
known-to-be-broken-site out there.
Well, the only protocols we handle are 1.0 and 1.1 (we handle 0.9, but don't
support sending it). The http specs say that servers should ignore the minor
version for this, and the bit talking about the 505 error explicitly mentions
the major version.

So this leaves us with 3 cases:

- We send an http/1.x request to a server which only supports http/2.x. In this
case, we couldn't do anything, since we don't suport 2.x.
- We send an http/1.1 request to a server which only udnerstands 1.0, and
erroniously rejects our request. Since the 505 error code was only introduced in
1.1, it wouldn't be sending this to us, and would probably send a 400/500
response. Again, we can't do anything.
- We send a http/0.9 request to a server which doens't support it (I don't think
we support doing this, but...). 0.9 doesn't support response codes, so the
server couldn't let us know.

IOW, I think that until HTTP/2.0 comes out, theres nothing we can do here, and
adding this woudl jsut add code complexity for a code path which would never be

Comment 16

16 years ago
Bradley: you're forgetting sending a 1.0 request to an 0.9 server.  FWIW, I
don't believe this will actually happen in practice often enough to warrant
implementing it, but it may be an issue when 2.0's nearing fruition.
No, I'mn not forgetting 0.9 servers. Not only was this status code only
introduced for 1.1, but 0.9 servers don't send a status line at all, so theres
no way of getting any error code.

When (if) HTTP/2.0 comes along, then we can revisit this, I guess.

Comment 18

12 years ago
-> default owner
Assignee: darin → nobody
QA Contact: tever → networking.http
Target Milestone: Future → ---
http/2 doesn't use this mechanism.. if it becomes necesarry we can open a fresh issue
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.