0.107.0 버전

저장망 쪽이 업로드 요청을 거절할 때, 그것이 요청 탓인지 서비스 탓인지를 답이 말해 줍니다.

그쪽에서 오는 거절이 전부 「윗단에 문제가 있다」는 한 가지 답으로 돌아왔고, 그 답은 다시 해 보라는 뜻입니다. 그런데 내용 때문에 거절된 요청은 몇 번을 다시 보내도 똑같이 거절되고, 하루치 지출 한도는 애초에 고장이 아닙니다. 이제 셋이 갈립니다 — 요청을 고쳐야 하는 경우, 한도가 풀릴 때까지 기다리는 경우, 진짜 고장인 경우. 크레딧에 일어나는 일은 그대로입니다: 셋 다 크레딧을 쓰지 않고, 어느 경우에도 돌려드립니다.

파일 목록이 7.5 MB쯤을 넘으면 저장이 되지 않았습니다. 안내에 적힌 8 MiB가 이제 실제로 상한입니다.

파일 이름과 폴더 구조는 브라우저가 암호화한 목록 안에만 있어서, 파일이 아주 많은 드라이브는 그 목록이 큽니다. 어느 크기를 넘으면 저장이 실패하는 것이 아니라 30초를 멈춰 있다가 「Internal Server Error」 한 줄로 돌아왔고, 그 답은 참인 것을 하나도 말하지 않았습니다. 원인은 서버 안이 아니라 그 앞에 있었습니다 — 웹 앱이 지나가는 요청의 본문을 한 벌 복사하는데 그 상한이 서버 자신의 상한보다 낮았고, 넘으면 알리지 않고 잘라 버려서 서버가 오지 않을 나머지를 기다렸습니다. 이제 그 상한이 서버의 상한 위에 있고, 서버가 받지 않는 크기는 곧바로 거절되며, 본문이 오다 멈춘 요청도 더는 붙들려 있지 않습니다.

「이 기기의 기억을 지우고 받기」가 정작 그 화면이 뜨는 기기에서 아무 일도 하지 않았습니다. 이제 동작하고, 그 선택은 언제나 사용자 몫입니다.

기기는 지금까지 연 파일 목록의 가장 높은 버전 번호를 기억해 두고 서버가 그보다 옛 목록을 보내면 걸러 내며, 그때 화면은 빠져나갈 길을 하나 내줍니다 — 서버가 보낸 것을 받고 이 기기의 기억을 지우는 것입니다. 그것이 동작하지 않았습니다: 기억을 지워도 옛 사본은 기기 안 캐시에 그대로 남아 있었고, 그 사본을 여는 순간 기억이 도로 세워져 서버의 목록이 또 거절됐습니다. 이제 그 버튼을 누른 다음 한 번은 캐시를 열지 않고 서버만 읽습니다 — 확인 창이 처음부터 약속하던 동작입니다. 이것을 기계가 스스로 판단하던 갈래도 지웠습니다: 그 판단은 계정이 만들어진 시각을 견주는 것이었는데 그 시각도 같은 서버가 주는 값이므로, 답이 정반대인 물음은 이제 언제나 계정을 가진 분에게 갑니다.

거절하는 답이 보내신 내용을 그대로 되돌려주거나 서버가 무엇으로 만들어졌는지 말하지 않습니다.

어떤 칸에 형식이 맞지 않는 값을 보내면 그 답을 쓴 것은 저희가 아니라 웹 프레임워크였습니다 — 그 칸이 쓰는 숫자 형식의 이름과 읽는 데 쓰인 꾸러미들, 그리고 길이 제한 없이 보내신 값 전체가 그대로 돌아왔습니다. 그중 요청하신 분께 도움이 되는 것은 하나도 없고, 도움이 되는 하나인 「어느 칸이 틀렸는가」는 그대로 남습니다. 이제 그 답은 정해진 문장 몇 개 중 하나와 칸 이름입니다. 앞으로 프레임워크가 거절 문구를 바꾸면 답은 더 말하는 쪽이 아니라 덜 말하는 쪽으로 물러나고, 저희가 알아채도록 시험이 실패합니다.

운영자만 쓰는 주소 둘이 운영 키를 보기 전에 자기 자신에 대한 물음에 답하고 있었습니다. 이제 둘 다 먼저 거절합니다.

이 통로들은 첫 줄에서 열쇠를 보지만, 웹 프레임워크는 그 줄이 돌기 전에 요청 본문을 먼저 읽습니다 — 그래서 열쇠가 하나도 없는 요청에게 「본문에 어느 칸이 없다」고 알려 주고 있었고, 그것은 그 주소가 있다는 것과 무엇을 받는지를 함께 알려 줍니다. 같은 틈은 일주일 전 관리 주소들에 대해 닫았는데, 이 둘은 그 옆에 있었고 빠졌습니다 — 그때 만든 시험이 주소를 하나만 두드렸기 때문입니다. 이제 검사는 목록이 아니라 소스를 읽습니다: 운영 키 없이 거절하는 통로는 전부 먼저 답하는 층 뒤에 있어야 하고, 지금 스물아홉 개를 셉니다.